[ClusterLabs] iSCSI Target resource starts on both nodes -- despite my colocation constraint
Ken Gaillot
kgaillot at redhat.com
Tue Jun 25 13:26:35 EDT 2019
On Mon, 2019-06-24 at 14:45 -0500, Bryan K. Walton wrote:
> On Mon, Jun 24, 2019 at 12:02:59PM -0500, Ken Gaillot wrote:
> > > Jun 20 11:48:36 storage1 crmd[240695]: notice: Transition 1
> > > (Complete=12, Pending=0, Fired=0, Skipped=0, Incomplete=0,
> > > Source=/var/lib/pacemaker/pengine/pe-input-1054.bz2): Complete
> > > Jun 20 11:48:36 storage1 pengine[240694]: error: Resource
> > > targetRHEVM is active on 2 nodes (attempting recovery)
> >
> > This means that pacemaker found the target active on storage2
> > *without*
> > having scheduled it there -- so either something outside pacemaker
> > is
> > setting up the target, or (less likely) the agent is returning the
> > wrong status.
>
> Thanks for the reply, Ken. I can't figure out what might have caused
> these iSCSI targets to already be active. They aren't configured in
> targetcli (outside of Pacemaker) and I have no scripts that do
> anything
> like that, dynamically.
>
> I don't have a default-resource-stickiness value set. Could that
> have
> caused the iSCSI targets to be brought up on the node that was being
> brought out of standby?
No stickiness wouldn't affect it.
Have you tried checking whether the target is really active before
bringing the node out of standby? That would narrow down whether the
issue is in pacemaker or earlier.
I'd double-check it isn't enabled in systemd. Another possibility is if
some other systemd service requires the target, systemd might start the
target even though it's not enabled (I believe the only way around that
would be to put the other service under cluster control as well).
>
> Thanks!
> Bryan
>
--
Ken Gaillot <kgaillot at redhat.com>
More information about the Users
mailing list