[Pacemaker] Question about the resource to fence a node

Andrew Beekhof andrew at beekhof.net
Fri Nov 15 00:36:18 UTC 2013


On 14 Nov 2013, at 5:53 pm, Kazunori INOUE <kazunori.inoue3 at gmail.com> wrote:

> Hi, Andrew
> 
> 2013/11/13 Kazunori INOUE <kazunori.inoue3 at gmail.com>:
>> 2013/11/13 Andrew Beekhof <andrew at beekhof.net>:
>>> 
>>> On 16 Oct 2013, at 8:51 am, Andrew Beekhof <andrew at beekhof.net> wrote:
>>> 
>>>> 
>>>> On 15/10/2013, at 8:24 PM, Kazunori INOUE <kazunori.inoue3 at gmail.com> wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> I'm using pacemaker-1.1 (the latest devel).
>>>>> I started resource (f1 and f2) which fence vm3 on vm1.
>>>>> 
>>>>> $ crm_mon -1
>>>>> Last updated: Tue Oct 15 15:16:37 2013
>>>>> Last change: Tue Oct 15 15:16:21 2013 via crmd on vm1
>>>>> Stack: corosync
>>>>> Current DC: vm1 (3232261517) - partition with quorum
>>>>> Version: 1.1.11-0.284.6a5e863.git.el6-6a5e863
>>>>> 3 Nodes configured
>>>>> 3 Resources configured
>>>>> 
>>>>> Online: [ vm1 vm2 vm3 ]
>>>>> 
>>>>> pDummy (ocf::pacemaker:Dummy): Started vm3
>>>>> Resource Group: gStonith3
>>>>>   f1 (stonith:external/libvirt):     Started vm1
>>>>>   f2 (stonith:external/ssh): Started vm1
>>>>> 
>>>>> 
>>>>> "reset" of f1 which hasn't been started on vm2 was performed when vm3 is fenced.
>>>>> 
>>>>> $ ssh vm3 'rm -f /var/run/Dummy-pDummy.state'
>>>>> $ for i in vm1 vm2; do ssh $i 'hostname; egrep " reset | off "
>>>>> /var/log/ha-log'; done
>>>>> vm1
>>>>> Oct 15 15:17:35 vm1 stonith-ng[14870]:  warning: log_operation:
>>>>> f2:15076 [ Performing: stonith -t external/ssh -T reset vm3 ]
>>>>> Oct 15 15:18:06 vm1 stonith-ng[14870]:  warning: log_operation:
>>>>> f2:15464 [ Performing: stonith -t external/ssh -T reset vm3 ]
>>>>> vm2
>>>>> Oct 15 15:17:16 vm2 stonith-ng[9160]:  warning: log_operation: f1:9273
>>>>> [ Performing: stonith -t external/libvirt -T reset vm3 ]
>>>>> Oct 15 15:17:46 vm2 stonith-ng[9160]:  warning: log_operation: f1:9588
>>>>> [ Performing: stonith -t external/libvirt -T reset vm3 ]
>>>>> 
>>>>> Is it specifications?
>>>> 
>>>> Yes, although the host on which the device is started usually gets priority.
>>>> I will try to find some time to look through the report to see why this didn't happen.
>>> 
>>> Reading through this again, it sounds like it should be fixed by your earlier pull request:
>>> 
>>>   https://github.com/beekhof/pacemaker/commit/6b4bfd6
>>> 
>>> Yes?
>> 
>> No.
> 
> How is this change?

Thanks for this.  I tweaked it a bit further and pushed:

https://github.com/beekhof/pacemaker/commit/4cbbeb0

> 
> diff --git a/fencing/remote.c b/fencing/remote.c
> index 6c11ba9..68b31c5 100644
> --- a/fencing/remote.c
> +++ b/fencing/remote.c
> @@ -778,6 +778,7 @@ stonith_choose_peer(remote_fencing_op_t * op)
> {
>     st_query_result_t *peer = NULL;
>     const char *device = NULL;
> +    uint32_t active = fencing_active_peers();
> 
>     do {
>         if (op->devices) {
> @@ -790,7 +791,8 @@ stonith_choose_peer(remote_fencing_op_t * op)
> 
>         if ((peer = find_best_peer(device, op, FIND_PEER_SKIP_TARGET
> | FIND_PEER_VERIFIED_ONLY))) {
>             return peer;
> -        } else if ((peer = find_best_peer(device, op,
> FIND_PEER_SKIP_TARGET))) {
> +        } else if ((op->query_timer == 0 || op->replies >=
> op->replies_expected || op->replies >= active)
> +                   && (peer = find_best_peer(device, op,
> FIND_PEER_SKIP_TARGET))) {
>             return peer;
>         } else if ((peer = find_best_peer(device, op,
> FIND_PEER_TARGET_ONLY))) {
>             return peer;
> @@ -801,8 +803,13 @@ stonith_choose_peer(remote_fencing_op_t * op)
>              && stonith_topology_next(op) == pcmk_ok);
> 
>     if (op->devices) {
> -        crm_notice("Couldn't find anyone to fence %s with %s", op->target,
> -                   (char *)op->devices->data);
> +        if (op->query_timer == 0 || op->replies >=
> op->replies_expected || op->replies >= active) {
> +            crm_notice("Couldn't find anyone to fence %s with %s", op->target,
> +                       (char *)op->devices->data);
> +        } else {
> +            crm_debug("Couldn't find verified device to fence %s with
> %s", op->target,
> +                       (char *)op->devices->data);
> +        }
>     } else {
>         crm_debug("Couldn't find anyone to fence %s", op->target);
>     }
> 
> 
>>>> I'm kind of swamped at the moment though.
>>>> 
>>>>> 
>>>>> Best Regards,
>>>>> Kazunori INOUE
>>>>> <stopped_resource_performed_reset.tar.bz2>_______________________________________________
>>>>> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
>>>>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>>>>> 
>>>>> Project Home: http://www.clusterlabs.org
>>>>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>>>>> Bugs: http://bugs.clusterlabs.org
>>> 
>>> 
>>> _______________________________________________
>>> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
>>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>>> 
>>> Project Home: http://www.clusterlabs.org
>>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>>> Bugs: http://bugs.clusterlabs.org
> 
> _______________________________________________
> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
> 
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20131115/f4c11807/attachment-0004.sig>


More information about the Pacemaker mailing list