[DRBD-user] Three node cluster?

Florian Haas florian at hastexo.com
Tue Apr 17 19:08:33 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 Tue, Apr 17, 2012 at 3:05 AM, Arnold Krille <arnold at arnoldarts.de> wrote:
> Hi,
>
>
> On 15.04.2012 22:05, Björn Enroth wrote:
>>
>> I am looking for information of how to deal with a KVM three node cluster
>> with DRBD
>> I have a "baby machine" ubuntu 11.10 pacemaker/drbd cluster with two
>> nodes,
>> local disks with drbd setup in between. This is working flawless.
>>
>> My challenge now is that I want to add a third node with the same setup.
>> How do I handle drbd in this setup? I'd like to have all nodes active, to
>> be able to migrate resources, mainly kvm virtual guests, around the
>> cluster
>> as I see fit. I'd also like pacemaker to be able to dynamically handle the
>> load.
>
>
> While drbd is great, this is exactly our intended use-case and also exactly
> the reason I am looking at other storage solutions. drbd can't do more than
> two nodes.
>
> You can of course distribute the drbd-resources so that some are n1/n2, some
> n2/n3 and some n1/n3, but that becomes an administrators nightmare. And once
> you decide that you need four nodes with the data present on at least three
> nodes, you are stuck.
> You can layer the drbd-resources but that is more meant for semi-distant
> mirrors and manual fail-over.
> And if you want live-migrations for your vms with more then two primary
> filesystem nodes...
>
> I am currently looking at glusterfs, there is also moosefs and ceph(fs), but
> only the first is meant to be stable enough that redhat gives commercial
> support for it. There are also other distributed cluster filesystems like
> lustre, but they lack redundancy.

FWIW, I agree that GlusterFS is probably the best available option at
this time, for this use case. I'd recommend Ceph (Qemu-RBD,
specifically) if the virtualization cluster was larger, but the
GlusterFS option combines excellent ease-of-use with good redundancy
and would probably be your best bet for this cluster size.

Cheers,
Florian

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



More information about the drbd-user mailing list