Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
/ 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. > > I would do it like so.... > > 1. Setup DRBD to sync locally and do your initial sync. > 2. Stop the DRBD/heartbeat daemon on the secondary and make sure it is not > going to restart under an rc script when it boots the next time. > 3. Stop DRBD/heartbeat on the primary and be sure it too is not loading > DRBD/heatbeaton boot up. there is no actual need to stop it on the primary, as long as the change rate is not too high. which is should not be anyways, because otherwise the low bandwidth of the distance link will kill your local io performance, too, and the system becomes not practically useable anyways. after the reconnect, this time one the distance link, there will be an incremental sync. > 4. Ship the secondary to your remote location. > 5. Update the drbd.conf and ha.cf to have the correct new IP information > (after testing you have a good connection of course) and pay close attention > to your timeouts as a little latency in a link may cause heartbeat or DRBD > to be flopping all over the place. > 6. Startup drbd and heartbeat then test for failover using hb_standby or > whatever else you want to try. > > Be sure you are using protocol C too. (Though, here is no real reason to > ever using anything but protocol C) well. there indeed is, in this case, a reason to try and use A, which is intended to be used on high latency links. -- : Lars Ellenberg Tel +43-1-8178292-0 : : LINBIT Information Technologies GmbH Fax +43-1-8178292-82 : : Schoenbrunner Str. 244, A-1120 Vienna/Europe http://www.linbit.com : __ please use the "List-Reply" function of your email client.