Quoting Francis Avila <[EMAIL PROTECTED]>: > From: "Chris Thomas" <[EMAIL PROTECTED]> > > I was wondering; is it better to have 2 LTSP servers handle a lab of 30 > > terminals or is it better to have 1 LTSP box and one App server handle 30 > > terminals? I ask this because I've heard some people have multiple LTSP > > boxes and I have also heard people have only one LTSP box and multiple > app > > servers. What do you guys think about these two solutions? > > Thanks. > > I can't answer your question, but I can offer some thoughts. > > First you need some more precise terminology, because you seem to use the > word 'LTSP box' equivocally here. Remember that 'LTSP' involves many > different parts, any of which can be divided or subdivided to different > machines. > > There's DHCP, TFTP, and client's root-NFS. After that are the application > servers, which run your X-clients. There is also the matter of home > directories. 'LTSP' can refer to the whole system together, to the first > three together, or even to only the client root-NFS (which is really the > core of the LTSP package. The rest are normal services that are configured > a certain way.) > > Of course, with the first three (DHCP, TFTP, NFS) you can have each on a > different machine, but since the load for those services is so slight, it's > probably not worth the additional complexity. I will refer to these as > 'LTSP services', to distinguish them from the applications. > > The real flexibility is the app servers. I have to come up with a solution > for around 50 clients, and so I've thought about this quite a bit, and > there > really isn't much help that I've found for those designing servers for LTSP > use--the most common advice is simply to get a machine and try it, and then > find bottlenecks and eliminate them. However, most important on individual > servers seems to be ram and cpu, in that order, with disk i/o and a network > card a more distant collective third. Don't be afraid to max out your > motherboard's ram capacity. And for cpu, better to get one with a large > cache (like a Xeon) than a small one (Celerons, for example, tend to > perform > much worse in proportion to their speed for ltsp, because of their small > cache). > > There are at least five ways I thought of to deal with app servers: one is > to have LTSP services and the apps on the same machine, second to have a > different app on each machine, and third is to alternate apps between > machines, and fourth is to do some sort of process-level load sharing, > namely MOSIX. The fifth is to use your display manager to choose a server > to provide X clients, through indirect XDMCP requests. > > First: all apps on one machine. This is, of course, simple to set up, but > for larger numbers of clients it may require a prohibitively large and > exotic server. It isn't just a matter of cpu and ram: first there will be > hd i/o bottlenecks, then network card bottlenecks, and maybe even bus > bottlenecks (although performance will probably have been slaughtered > before > things get this bad). Network bottlenecks are especially troublesome: even > with a switched 100BaseT network, the pipe from server to switch is only > 100Mbps. However, this pipe must serve every single client. If you have > 50 > clients sharing a 100Mbps pipe, you're going to have bottlenecks. The only > way around this that I can see is some sort of channel bonding, where you > have two or more network cards that are considered by the kernel to be a > single ip address, and network load is shared among them. But this would > require a switch that also knew about this, and divided load accordingly. > I > don't have the network expertise to say anything more on this matter, and I > don't even know if its possible. > > Second: Different app on each machine. This would involve a main app > server, which provides the display manager, and then various rsh > machinations to run different apps on different servers. This is a bit > more > complex and less flexible to set up, and doesn't help you if you happen to > have all your clients clamoring for the same application--one server will > be > bursting while the others are doing nothing. However, there might be some > b > enefit with single-app servers: since they only run one application, their > load is very predictable: the cache would soon be filled with only what was > necessary, there would be no overhead from running multiple applications > (like with having to load and unload unshared libraries), and so on. This > might all be negligible in the end, though--I'm only speculating. > > Third: Alternate-app servers. All app servers serve the same apps, but > alternate between different client invocations. This is like a printer > pool. > The only thing different is that scripts to run the apps would keep track > of > which server was last invoked. > > It would seem also that any of the rsh-between-servers solutions would > increase network load on the main server (unless network topology were > adjusted accordingly), as any connection would have to go from client to > main (display manager) server to app server to main server to client, even > if a direct route existed between client and app server. This would > probably make it slower, too. Maybe what one can do is rsh into the client > and tell it to rsh into the needed server to run its app. This becomes > increasingly periphrastic. > > Fourth: MOSIX. I've never touched mosix, so I don't know how useful it > would be for this. Mosix divides process load among multiple machines. > This is done on a per-process basis, which distinguishes it from things > like > beowulf clusters, which have for each machine a different process working > on > different data, and the machines don't interact with one another while > doing > their actual cpu work. It seems Mosix uses a lot of network bandwidth, and > indeed the network is probably the biggest bottleneck and may destroy and > benefit of load sharing. However, you won't have to do any of the > shell-scripting stuff above: you'll have a main server that runs the > application, and if it runs low on resources, load gets shifted to other > machines. I think this would only help with cpu resources, however, not > with ram or other problems. Once again, more investigation needed. There > is a doc in the contrib section of the LTSP web site that discusses using > MOSIX to share load between server and clients. You might want to check > that out, too. > > Fifth: XDMCP redirects. This involves running a display manager on every > server, and then having the client be directed to a different display > manager based upon server load. The servers themselves would offer > identical services. I don't know how one would automate the process of > choosing a server--traditionally, the user just gets a big menu of > available > servers and their ping times. Better would be a transparent redirect based > upon actual server load. This is even more like a printer pool than option > three above. Once a user logs in, the only way to switch to a new server > is > to log out and then back in again. Plus, you'll probably have to do NFS > sharing of home directories among servers, and maybe even NIS/LADP for > things like password files. > > I'm leaning towards option two, although five sounds attractive. But I > suppose what you should do depends mostly on what kinds of apps you're > running, and how many. Also, the critical point where it's cheaper to buy > a > mondo server than two smaller ones can be difficult to determine, and > anyway, there are factors other than cost involved here. > > Comments and ideas welcome! > -- > Francis Avila
Francis, Thanks for taking the time to lay out all those options. I've been wrestling with this stuff myself as our LTSP installation grows. I have chosen the app server approach (option 2) for a couple of reasons. I have a main login server that handles the logins/window managers and many of the applications. I have added another server and run some apps via rsh on the second server. A couple of the advantages I see with the separate app server model are. 1. In the event that an app runs wild and crunches the processors, or a machine fails for some reason, only the apps offered by that server are affected. So if netscape eats up all the processor on the "netscape app server" people start having problems with netscape. They can still use all other apps that are not on that server. Of course this doesn't work if it is your main login server that goes down :-) I have been starting to think about high availability clustering for the login server. 2. Maintenance. I am adverse to maintaining multiple boxes that are supposed to be exactly the same. Software upgrades/bug fixes, etc. eventually get out of sync, and users start noticing that they are connected to the "good" server or the "bad" server. With application servers, the users always get the exact same version of any given app and you only need to update/maintain it in one place. I think scalability and high availability are two logical next steps for LTSP. Those are a couple of good problems to have. :-) The reliability of our LTSP system is so good that it is bound to keep growing. Derek -- Derek Dresser Gould Academy Bethel, ME 04217 (207)824-7700 ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.openprojects.net
