[DRBD-user] Reasons not to use allow-two-primaries with DRDB

karel04 at gmail.com karel04 at gmail.com
Mon May 21 18:24:17 CEST 2012

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


Hey,

thank to all three of you for the comments, it helped me pathing my
way through the whole stuff.

> On 05/19/2012 01:54 PM, Arnold Krille wrote:
>> A) There is a huge performance gain from using extX over gfs2/ocfs2,
Yes, I underestimated the effects of cluster systems. Btw. here is an
older discussion I found
http://oss.oracle.com/pipermail/ocfs2-users/2009-April/003472.html
about the speed of OCFS2.  The interesting part for me was the local
mode.  I have not made benchmarks yet, but if speeds are roughly
equivalent, one could use OCFS2 for all DRBD volumes and have the easy
option to upgrade to two-primaries setups without moving data around
or change the filesystem.

>> B) There is a huge latency improvement when using protocol A or B over C. The
I see it now, as long as I do not hit bandwidth restrictions, DRBD is
de facto invisible.

> Digimer wrote
>  Clustered file systems require some form of clustered locking. GFS2
> uses DLM, not sure what OCFS2 uses.
I am not using automated failovers, so I decided to go the easy way
and use the OCFS2 legacy setup.  I found it much easier to set up,
then clvm.

>  You *should* have fencing (aka 'stonith') with DRBD, but you
> absolutely *must* have it for dual-primary, or else you will end up with
> a split-brain and likely data loss.
This turned out to be one of the hardest parts to grasp.  When I first
tried activating my dual primary volume, not only did my server go
down and reboot (the locking systems of the Kernels had incompatible
versions), but it also instantaneously it killed the other one.  At
that point I realised what Stonith stands for and what those default
scripts were up to. :)

If the split brain problem only was something at the file system level...

The lesson I learned, is that I do not want to use dual-primaries for
any "important" stuff, without some cluster manager and according
rules that keep the show going.  The one way setups recover nicely
from any network trouble and without automated switchovers the
recovery is trivial.  But to enable real dual primary setups I first
would have to implement some logic on my application level.

> Regarding Florians question about GlusterFS
I think I tried it both over the network as well as with two local
nodes, but I was doing it with my applications in mind.  The biggest
advantage I hoped to achieve, was to use distributed and replicated
setup (eg. 4 nodes, 2 replica setup)  I was happy with write speeds,
but it only occurred to me by coincidence that read access is not
instantaneous even when the files are fully replicated.  So that was a
show-stopper.

Thanks again for your help.



More information about the drbd-user mailing list