On Wed, Sep 25, 2002 at 03:19:35AM -0600, Tom Lisjac wrote: > > I'm new to the list and apologize if this question has been asked > before. My searches have come up empty so I thought I'd ask here.
There has been some discussion on this topic, but IMHO there are several ways that seem good. > Over the Summer, I've set up an LTSP system with 10 terminals at a local > elementary school where LTSP was able to save a lot of perfectly good > equipment from being retired! This lab has made Linux is available to a > lot of kids who wouldn't have had access to a computer this year! :) > > I'm running the 10 machines off a single P-III 450 with a gig of ram. > I'd like to set these labs up in other schools... but the single point > of failure and lack of scalability makes me nervous about the existing > lab let alone a larger deployment. > > I'd like to add another identical P-III 450 (we have lots of these) as a > load sharing and fail-over LTSP server. If one server goes down, I'd > like the lab to simply slow down... not stop. I was wondering if anyone > could point me at a preferred way of doing this? I have a few ideas but > I'd rather not re-invent the wheel! :) > > My current plan is to use the Linux-HA link to ping-pong the DHCP > servers on the two machines. Each time a client boots, the active server > would stop it's local DHCP server and pass control to the other box. > This would effectively split the load. In the event of a failure, a > heartbeat script could permanently enable the surviving machine's DHCP > server. The failed box could then be removed and replaced without > disrupting the classroom environment. It has been suggested to have the two identical servers compete about the DHCP call, the one with least load for the moment will win, and take care of the client. AFAIK the only complexity that this sheme adds is to sync /home on the two servers. My first suggestion would be to have a logout script, but there is definately no easy solution that can guarantee that this script will be called (I have not tried to look-in users in X, but it seems hard), so another way would be to have a startup script that can be started from the display-manager. kdm, and others also I believe, have a script called Xstartup which could be used for spawning a rsync. The only con with that, is that is will slow down the login process a bit. In Debian the script is in /etc/kde2/kdm/ but the standard location (for xdm) would be /etc/X11/xdm/, gdm is different, I have heard. Actually you could use a combination of these: do a logout script and make the window-managers exit function execute it. Make the logout script add a file (on the other server) that shows that it has synced. In the startup-script, exit if that file exists, else sync, and remove the file that implies that the directories are in sync. A setup like that would be fast in the normal case, and work if the logout script was never executed (or failed). Be sure not to make the startup script rely on being able to sync, since that would completely defeat the purpose (to be able to continue even if one server goes down)! > If there's an easier or better way of doing this, any suggestions would > be greatly appreciated! How do others on this list sync /home? -- Hans Ekbrand
msg08146/pgp00000.pgp
Description: PGP signature
