Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Tue, Aug 18, 2015 at 09:31:33PM +0200, Matthias Ferdinand wrote:
> On Tue, Aug 18, 2015 at 06:22:10PM +0200, Lars Ellenberg wrote:
Taking this back on the list.
Sorry for accidentally taking it offlist before.
> > > I think there is a conceptual bug in the DRBD OCF RA with multi-volume.
> >
> > You don't happen to use the DRBD ocf agent from drbd utils 8.9.3 ?
> > If so, you want the one from git (or 8.9.3-2).
> >
> > see also git.linbit.com/drbd-utils.git
> > the three commits drbd.ocf following the v8.9.3 tag.
>
> Hi, thanks for answering. The server has drbd8-utils 8.4.4 installed
> (Ubuntu 14.04). The drbd.ocf from git is the same as in
> drbd-utils-8.9.3.tar.gz.
Ok. We had a broken drbd.ocf with the "8.9.3" tag out there,
I then bumped it to 8.9.3-2 (and the tarball meanwhile as well).
> There are some cleanups/sanitizing compared to
> 8.4.4, but afaict (just reading the source) it has the same problem:
>
> drbd_status() returns $OCF_RUNNING_MASTER as soon as any of the volumes
> is in role "Primary", even if some volume was still in role "Secondary".
>
> 525 drbd_status() {
> ...
> 558 drbd_set_status_variables
> 559 case "${DRBD_ROLE_LOCAL[*]}" in
> => 560 *Primary*)
> 561 rc=$OCF_RUNNING_MASTER
> 562 ;;
>
>
I apparently misread your original report.
Yes, that is the case, and the above is intentional.
Though I don't remember all of the reasoning right now. Probably has
something to do with adding a volume to an existing resource.
If you want independent volumes, use independend resources.
Volumes in the same resource are supposed to be promoted/demoted
together.
With drbd 8.4, that is not yet actually properly "enforced" always, though.
> A workaround might be an additional variable indicating wether the roles
> of all volumes are identical or not. How to react to such an
> OCF_RUNNING_WITH_MIXED_ROLES(tm) situation probably depends on the
> target role. drbd_promote() and drbd_demote() could keep on re-trying
> the promote/demote operation until all volumes have reached the desired
> role (or timeout). What to return to pacemaker as a monitor result - I
> don't know.
Pacemaker would not have any way to deal with a "partially promoted" DRBD.
Pacemaker can
* call resource agents with start/stop/promote/demote/monitor/some/other
* kill other nodes (via fencing)
* fill up logs until ENOSPC
* kill itself
the last two may be redundant ;-)
> > > Function drbd_status() returns $OCF_RUNNING_MASTER if the string
> > > of the local role values _contains_ the keyword "Primary", i.e. if _any_
> > > of the volumes is in the primary role.
> > >
> > > This is fine if you check e.g. the effect of a demote operation. When
> > > checking for the success of a promote operation, you should make sure
> > > _all_ of the volumes are in the primary role.
> > >
> > >
> > > I therefore think drbd_promote() and drbd_demote() should have their own
> > > status functions (or a parametrized one).
You suggest that a "promote" fails (or keeps trying),
if any of the volumes cannot be promoted,
and a "demote" fails (or keeps trying),
if any of the volumes cannot be demoted.
"monitor" would need to report "running master" if at least one volume
is Primary, otherwise Pacemaker would not schedule a demote when
necessary. Possibly "failed master", if we find a mix of Primary and
Secondary volumes.
Sounds reaonable enough.
Anyone cares enough to prepare a patch?
--
: Lars Ellenberg
: http://www.LINBIT.com | Your Way to High Availability
: DRBD, Linux-HA and Pacemaker support and consulting
DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.