[DRBD-user] DRBD Dual Primary + GFS2 for redundant KVM hosts

A.Rubio aurusa at etsii.upv.es
Sat Aug 26 11:08:57 CEST 2017

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

Hi all.

I writted a book about this every years ago for a course.

The book is about pacemaker, drbd, gfs2 and kvm, for 2 nodes and for 
many nodes.

It's writted in spanish because my english is poor (it's evident :-()


If yo want a copy and you can't buy it ;-), You write to my. I don't 
have problem send you the ebook.

El 25/08/2017 a las 22:18, Digimer escribió:
> On 2017-08-25 04:08 PM, Gionatan Danti wrote:
>> Il 25-08-2017 22:01 Digimer ha scritto:
>>> On 2017-08-25 03:37 PM, Gionatan Danti wrote:
>>> The overhead of clustered locking is likely such that your VM
>>> performance would not be good, I think.
>> Mmm... I need to do some more testing with fio, it seems ;)
>>> With raw clustered LVs backing the servers, you don't need cluster
>>> locking on a per-IO basis, only on LV create/change/delete. Because LVM
>>> is sitting on top of DRBD (in dual-primary), live-migration is no
>>> trouble at all and performance is good, too.
>> True.
>>> GFS2, being a cluster FS, will work fine if a node is lost, provided it
>>> is fenced succesfully. It's wouldn't be much of a cluster-FS
>>> otherwise. :)
>> So no problem with quorum? A loss of a system in a two-node cluster
>> seems to wreack havok on other cluster filesystems (Gluster, for
>> example...)
>> Thanks.
> Quorum is optional (an often misunderstood thing).
> https://www.alteeve.com/w/The_2-Node_Myth
> We've run without quorum for every system we've built over 5+ years,
> across dozens of sites and never once needed it. A proper fence setup,
> which is needed regardless, is fine. In our opinion, the complexity of a
> third quorum node is not justified for the limited benefit of quorum.
> Simplicity is simply too valuable in HA.

More information about the drbd-user mailing list