On Wed, Nov 27, 2002 at 08:16:53PM +0700, Mohammad Ikhsan wrote: > Hello Hans, > > Wednesday, November 27, 2002, 3:58:59 PM, you wrote: > > thx for your explanation Mr Ekbrand, > > HE> Either you separate the networks physically, or you do it by MAC > HE> address. If you only want an even spread so that half of the client > HE> automatically connects to one server and the other half connect to the > HE> other, you could load balance with dchpd (but that only works for > HE> exactly two servers). Separating the networks physically will save > HE> bandwith, but make the system more sensitive (If one server is broken, > HE> the clients cabled to it will be unusable) > > I want to avoid to separate the networks physicaly. If it's posible i want to > make a group of clients to connect to a certain server, and if that > specific server are down, they can search for another LTSP server on > the networks to connect to. Is it posible?
Yes, by making one server the primary (in regards to dhcp) and another server secondary. That way if one of them is down, the other will be its standin (the servers continously test each other for availability, and you can even make A take over the others B clients if B is up, but not offering IPs as it should). This makes it easy to use two servers and I would recommend to NOT USE MORE THAN TWO SERVER ON THE SAME SUBNET anyway since network bandwith should not be wasted. If you have four servers, split them up in pairs. Tom Lisjac has written a nice HOWTO for setting up two identical LTSP servers on the same subnet here: http://theseus.sourceforge.net/projects/ets/ets-howto.html (It says its a beta version , but I think its good enough) The HOWTO presupposes that a another server will store /home and autentication will be done against that other server. If you want the two LTSP servers independent on other servers, realize that you must somehow sync /home and the autentification data). If you STILL want three (or more) servers on the same subnet, you could: a) configure the /opt/ltsp/i386/etc/rc.local so that clients use "-BROADCAST" instead of "-QUERY ip.of.boot.server" That way the first server that respondes to the XDMCP call will "win" the client. On the negative side is that the exact ratio you could define with options in dhcpd.conf will be gone, and the load at the time of the XDMCP call will determine which server will "win" the client. That might not be what you want. b) define - for some macaddresses - another server as the NFS root server. That way you decide which client goes to server C, but the price is that if C is down, the clients will not be usable. -- Hans Ekbrand
msg09844/pgp00000.pgp
Description: PGP signature
