[DRBD-user] drbd solution for distant sites ? (4MB line)

paddy paddy at panici.net
Fri Feb 24 11:37:31 CET 2006

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


On Thu, Feb 23, 2006 at 08:03:07PM +0100, Lars Ellenberg wrote:
> / 2006-02-23 13:02:37 -0500
> \ Chip Burke:
> 
> > > Now they want to put some distance between the two nodes -- just 700 Kms
> > :)
> > > the link will be a vpn connection up to 2 or 4 MB :(
> > > I've made some computes and as there is some 400 GB to synchronize, it 
> > > takes minimum 18 days to make the first sync if we stay in 2MB :(
> > 
> > You could probably perform the first sync locally.
> > 
> > > After this period I expect that synchronization would ask for less 
> > > resources... but is DRBD capable to function with such a link ?
> > > 
> > > I would know if DRBD is a good solution for my problem or we need to use 
> > > another way to make a common file server synchronized for our two sites.
> 
> um. just in case.
> "keep common file server synchronized" over 700km ...
> 
> you are aware that drbd is mainly a failover solution,
> not a "use identical data on both sides at the same time" thing.
> i.e. you can use your data here, and have it mirrored by drbd to your
> other site, as a backup for desaster recovery.
> 
> you could even do a (lvm) snapshot on the remote side,
> and mount that one readonly.
> 
> you CAN NOT however mount/access your data
> read/write on both locations at the same time.
> you'd need drbd 8 for that, which is not yet productin ready,
> AND you'd need a "cluster aware" file system, say OCFS2, and that would
> _really_ be no fun at all with the high latency over long distances.

700km would be what? 4ms? (although 4MB is going to add to that)
(I suppose double that for the round trip)

compare that with disk access times.

now compare the bandwidths.  much bigger difference ?

I think if you have a sequence of transactions, say locks you have to take
or whatever then 10ms is going to start to hurt pretty fast, but I would
have guessed that a cluster filesystem would avoid that where possible?

(mind you I'd also imagine that kind of thing being optimised for SAN-like 
situations, which is not exactly like 4MB over 700km ;)

What am I missing ?

Regards,
Paddy
-- 
Perl 6 will give you the big knob. -- Larry Wall



More information about the drbd-user mailing list