Re: [PATCH 00/12] DRBD: a block device for HA clusters

Nikanth K
2009-04-07T12:23:27Z

Hi Philipp,

On Mon, Mar 30, 2009 at 10:17 PM, Philipp Reisner
<philipp.reisner@linbit.com> wrote:
> Hi,
>
>  This is a repost of DRBD, to keep you updated about the ongoing
>  cleanups.
>
> Description
>
>  DRBD is a shared-nothing, synchronously replicated block device. It
>  is designed to serve as a building block for high availability
>  clusters and in this context, is a "drop-in" replacement for shared
>  storage. Simplistically, you could see it as a network RAID 1.
>
>  Each minor device has a role, which can be 'primary' or 'secondary'.
>  On the node with the primary device the application is supposed to
>  run and to access the device (/dev/drbdX). Every write is sent to
>  the local 'lower level block device' and, across the network, to the
>  node with the device in 'secondary' state.  The secondary device
>  simply writes the data to its lower level block device.
>
>  DRBD can also be used in dual-Primary mode (device writable on both
>  nodes), which means it can exhibit shared disk semantics in a
>  shared-nothing cluster.  Needless to say, on top of dual-Primary
>  DRBD utilizing a cluster file system is necessary to maintain for
>  cache coherency.
>
>  This is one of the areas where DRBD differs notably from RAID1 (say
>  md) stacked on top of NBD or iSCSI. DRBD solves the issue of
>  concurrent writes to the same on disk location. That is an error of
>  the layer above us -- it usually indicates a broken lock manager in
>  a cluster file system --, but DRBD has to ensure that both sides
>  agree on which write came last, and therefore overwrites the other
>  write.
>

So this difference to RAID1+NBD is required only if the DLM of the
clustered fs is buggy?

>  More background on this can be found in this paper:
>    http://www.drbd.org/fileadmin/drbd/publications/drbd8.pdf
>
>  Beyond that, DRBD addresses various issues of cluster partitioning,
>  which the MD/NBD stack, to the best of our knowledge, does not
>  solve. The above-mentioned paper goes into some detail about that as
>  well.
>

It would be nice, if you can list those limitations of NBD/RAID here.

Thanks
Nikanth