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

Florian Haas florian at hastexo.com
Mon May 21 14:06:22 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.


On Fri, May 18, 2012 at 6:29 PM, karel04 at gmail.com <karel04 at gmail.com> wrote:
> Hello,
>
> I am in the process of setting up DRBD on my servers, the network
> bandwidth being the bottleneck.  After having evaluated GlusterFS I
> realised, that I need the instant read access offered by DRBD.

Out of curiosity (even though this is slightly OT for this list), when
you tested GlusterFS did you mount your GlusterFS volume off of a
remote cluster (i.e. over the network), or did you mount on the same
node where the GlusterFS server was also running (i.e. mount the
volume from localhost)? Also, did you use a straight-up replicated
volume, or a distributed or distributed-replicated volume?

> Logically I am able to separate partitions that would require access
> from both nodes, and partitions where an asynchronous master-slave
> sync is sufficient.  But as far as I understand, the benefits from
> using Protocol A instead of C are limited, when the network is stable.

Make that "when the network has low latency and high throughput",
which is generally a given in LAN-like setups.

> My question:
> Are there any additional benefits from NOT using two primaries or
> additional risks when using it? eg. would there be significant
> performance gain by using ext4 instead of GFS2/OCFS2? Anything else I
> should take into consideration?

You've already stated that you're able to separate file access per
node. And you only want access from two nodes, otherwise you wouldn't
be considering DRBD. So, that makes your system a textbook use case
for two separate single-Primary DRBD resources. This type of setup is
orders of magnitude simpler to get right than a dual-Primary
configuration, as both Arnold and Madison (digimer) have pointed out
earlier. It completely sidesteps the issue of managing a cluster
filesystem, and if you're concerned about being able to grow your
filesystem later, just slap your DRBD resources onto LVM logical
volumes, and you can resize at will (to the extent that your
filesystem supports it).

Hope this is useful.

Cheers,
Florian

-- 
Need help with High Availability?
http://www.hastexo.com/now



More information about the drbd-user mailing list