[Linux-cluster] No storage cluster configuration

[Lon Hohberger]

On Thu, 2006-08-17 at 12:29 -0700, Michael Will wrote:
> How many other technologies are being kept out of redhat
> because of 'deep seated hatred of elite engineers'?

I should have used different phrasing.  I would like to apologize for my
previous email, because it came out the wrong way.

I don't remember what the original reasons were when I asked a few years
ago about it, but I remember the response wasn't particularly - shall we
say - "positive" towards DRBD.  This, however, was a long time ago.

Fast forward to now.  At this point, with cluster mirroring getting
closer to completion, it probably makes a lot of sense to just put
efforts in to that.  Combined with GNBD, it solves the same problem that
DRBD 0.8.x (unstable) solves - and has the benefit of LVM device-mapper
integration.

A couple of people have asked for a 'howto' for GNBD + cmirror, and I
think that would help a lot in understanding how it works, so I will try
to look into that in the next week or two.  Remember that cmirror isn't
quite 100% yet, but any help in testing will be, er, helpful.


> I am forced to sell (non-gfs based) fileservers with SLES9 simply
> because
> there is no XFS support in RHEL4. Or I have to go the centos route which
> has the centos-plus packages that reintroduce XFS, but then I can't sell
> redhat's support contracts.

> Same for desktops with proper KDE integration.

I'm going to dodge these; I'm pretty sure they've been beaten to death
plenty of times on other mailing lists, slashdot, and other places. ;)


> Now DRDB I did not know about but am certainly curious about - the last
> time I
> investigated that approach was with nbd / dnbd and did not result in a
> lot 
> of confidence or the feeling that it was actively maintained.

DRBD is actively maintained and developed.  You can even purchase
support for it, just not from Red Hat.

http://www.linbit.com/linhac_drbd.html

As far as making it work... linux-cluster simply lacks a resource-agent
to control DRBD in failover situations.  It's probably not hard to craft
one.

-- Lon