[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE: [Linux-cluster] No storage cluster configuration

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

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.


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

-- Lon

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]