Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'd like to consider the use of DRBD for data replication between a primary and secondary location. The initial plan is to establish a VPN tunnel between the two; the primary end using a slice of a dual T1 link and the secondary location setting on a cable / dsl line.

The secondary will exist for DR only - it will "never" replicate back to the primary.

Has anyone done/tired/using something like this and what are your experiences with it.

Linbit also has a (Paid) DRBD Proxy product that is supposed to be designed for operating across WAN type links (compression, multiple peers). Anyone tried this out?

share|improve this question
add comment

1 Answer 1

I can't speak for DRBD Proxy, but the regular DRBD will not like this much.

With even limited activity, you could easily saturate a dual T1 (2x 1.5Mbps; for round numbers, 300KB/s). 300KB/s could be taken up by application logging alone, let alone doing anything interesting on your server. This rules out synchronous replication (Protocol C), let alone adding the over-the-vpn latency into the equation.

Async replication (Protocol A) might technically work, but I would expect the secondary to be so far out of date as to not be usable in the case of a failure (the replica might be hours behind during the day)

Memory synchronous (Protocol B) won't help as it's still constrained by the bandwidth issue.

I expect DRBD Proxy will still suffer with similar issues, primarily causing replication delay due to the limited bandwidth.

I recommend you re-evaluate your DR strategy to work out what you are mitigating against; hardware failure or site failure.

In the case of protecting against site failure, you may get better mileage out of lower bandwidth / higher density transfers in the case of one (or both) bandwidth constrained site. Some examples of this technique are rsync (over-the-wire transfers are limited to changes in files between runs - rather than per-change for every change - plus some protocol overhead; can be run over SSH to encrypt and compress traffic further) and database log shipping (transferring compressed database logs to replay on the DR box may use less bandwidth than transferring a full database dump).

If you're protecting against hardware failure, a local DRBD replica connected with a GigE crossover will work just fine, allow for fully synchronous updates, and permit online verification to prove the data is consistent on both nodes. You can still combine this option with limited file replication to an DR site to protect against a primary site failure.

share|improve this answer
    
Thanks Greg. I've actually spoke with Linbit since posting the question and the proxy product sounds very promising. It specifically address latency, loss of connection, and lower bandwidth pipes. They use it internally between their US and overseas location across a 200ms latency line (not sure on the bandwidth though). I've got a demo next week to get more details. The solution needs to be block level so ssh / rsync don't fit. –  Jeff Hengesbach Jun 11 '09 at 15:43
    
I'd be really interested in hearing the outcome of your demo. Good luck! –  Greg Work Jun 12 '09 at 8:36
2  
The proxy product is 'more-or-less' a RAM based buffer with compression. The key is having enough RAM(and bandwidth) to handle the data's rate of change. So, great idea for office documents, low transaction db's and small data things, probably not good for multimeda, virtual machine images, and other large data changes. –  Jeff Hengesbach Jul 23 '09 at 15:31
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.