[ClusterLabs] design question to DRBD

[Dimitri Maziuk]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: OpenPGP digital signature
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20160625/9f15e7ad/attachment-0004.sig>