[Linux-cluster] Clustering Propagation Times?

[Dan Brown]

Hi,

This isn't a direct RHCS related question so feel free to point me to a
better list or respond off list, etc.

I've been following this list mostly for the purposes of attempting to get
my DRBD+GFS2+CMAN clustering working (so far unsuccessfully as it doesn't
appear to fence).  I don't think I've done any posting yet, just lurking. In
the mean time while troubleshooting DRBD I've been running two
geographically distant groups of web servers, replicating data to each other
in several groups of local/remote csync2 "clusters".  I guess it's not
technically a clustering system at all but rather a file mirroring system
similar to constantly rsync'ing files back and forth between each server
pair.  I've added some wrapper scripts to provide some locking and prevent
it from running synchronously since it tends to fail when it does.

Replication however still isn't a speedy process (hence my attempts to
utilize DRBD/GFS to satisfy those above me) with a minimum max replication
time of two minutes.  Replication is cron'd to run on one server during odd
minutes, on the other server on even minutes.  We've got a 2xT1 on one end
and a 10M line on the other.
A 100MB file for example would take 3 minutes 13 seconds to transfer or so
if both the local and remote connections were relatively idle and nearly
maxes out a 2xT1 line. A 512mb file about ten minutes.

I would suspect that other clustered disk replication technologies out there
(although I haven't seen many methods to do this other than DRBD, rsync, and
home brew solutions) would have similar replication times and be limited
almost entirely by connection speed and traffic congestion.

So how do you deal with replication delays in a web cluster where two
browsers hitting different servers are supposed to both be able to download
the same 50mb PDF but one server may not have that entire file yet.  Phrases
like "build scheduling into the CMS" tend to be like an old stick of
dynamite around here.

___
Dan Brown
danb at zu.com