On 06/23/2016 04:57 AM, Lentes, Bernd wrote: > > What i mean with "less complicated" is that i prefer to have everything > managed by pacemaker and not some stuff by pacemaker and some stuff by init. > This is more overseeable.
I'd agree to that except I am regularly locking up pacemaker-controlled
active/passive drbd with
> Jun 25 15:49:36 lionfish drbd(drbd_storage)[28984]: WARNING: raid still
> Primary, demoting.
> Jun 25 15:49:36 lionfish kernel: block drbd0: State change failed: Device is
> held open by someone
> Jun 25 15:49:36 lionfish kernel: block drbd0: state = { cs:Connected
> ro:Primary/Secondary ds:UpToDate/UpToDate r----- }
> Jun 25 15:49:36 lionfish kernel: block drbd0: wanted = { cs:Connected
> ro:Secondary/Secondary ds:UpToDate/UpToDate r----- }
> Jun 25 15:49:36 lionfish drbd(drbd_storage)[28984]: ERROR: raid: Called
> drbdadm -c /etc/drbd.conf secondary raid
> Jun 25 15:49:36 lionfish drbd(drbd_storage)[28984]: ERROR: raid: Exit code 11
> Jun 25 15:49:36 lionfish drbd(drbd_storage)[28984]: ERROR: raid: Command
> output:
> Jun 25 15:49:36 lionfish drbd(drbd_storage)[28984]: WARNING: raid still
> Primary, demoting.
-- repeat until I hit the power button. All it takes is adding a
resource that depends on drbd fs and fails to start.
So at this point I'm having doubts about active/passive drbd + pacemaker
being more maintainable than active-active drbd + gfs2. (That's of
course because I haven't looked into gfs lock manager: I'm sure it sucks
just as hard only differently.)
--
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
