On Wed, Sep 25, 2002 at 01:53:06PM +0200, Ragnar Wisl�ff wrote: > Sitat Hans Ekbrand <[EMAIL PROTECTED]>: > > > > > > > > rsync from cron. > > > > But what if a user logs out, and in again before the cron job is > > run? > > > > If you have load balancing rather than fail-over then you risk > that such a user ends up on the node that still has not been > synced with the contents of the other.
Indeed. And the solution I headed for combined load-balancing and fail-over. > For a fail-over solution, > the chances of someone logging out and then in again between > syncs - and the passive node having taken over from the active - > should be very small indeed. Yes, that was not the problem I thought of. > Anyway, rsync is smart enough to > only update what's changed in individual files, so the problem is > only transient. Unless you use shared storage it very difficult > to totally guard against data loss/corruption. Well, that is what I am trying to solve here. > Depending on load and capacity of servers and interlinking (I'd > say three NICs in such boxes - the additional for the syncing) > you should be able to have a frequency of 3 - 5 minutes between > syncs. Even with rsync running via ssh (and thus loading the > machines heavily) you can move a lot of data in 3 minutes on a > dedicated 100 Mb/s link. IMHO, a setup that only sync when it is needed (once per login/logout) is the only thing I would be satisfied with. Even though rsync is smart, it takes alot of CPU, and to run it frequent is a waste of CPU. If users seldom logout, a nightly rsync would be necessary of course. Also note that loadbalancing with double dhcp-servers might not work as you want it to, if the thin clients never reboot. -- Hans Ekbrand
msg08151/pgp00000.pgp
Description: PGP signature
