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 :-()
http://www.lulu.com/shop/aurelio-rubio-sapi%C3%B1a-and-juan-vicente-capella-hern%C3%A1ndez/pacemaker-clusters-de-alta-disponibilidad-para-servidores-virtualizados/ebook/product-22274638.html
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.
_______________________________________________
drbd-user mailing list
[email protected]
http://lists.linbit.com/mailman/listinfo/drbd-user
