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 ------------------------------------------------------- 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
