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 :-() 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. >