[ClusterLabs] Hypothetical question: transitions slow in one direction

[Reid Wahl]

On Friday, February 11, 2022, Reid Wahl <nwahl at redhat.com> wrote:
>
>
> On Friday, February 11, 2022, john tillman <johnt at panix.com> wrote:
>> Hypothetically, if I have a two node cluster on identical VMs without
>> fencing and I see transitions take longer in one direction than the
other.
>>  What are some possible reasons?
>>
>> For example, "pcs node standby nodeX" or "pcs cluster stop nodeX" results
>> in a very fast transition to nodeY.  However, given the same commands but
>> going from nodeY to nodeX takes much, much longer.
>>
>> And note that powering off either VM does *not* exhibit this behavior and
>> transitions times in both direction are the same, fast.
>>
>> Best regards,
>> -John
>>
>
> I'm assuming that in all cases, your resources are all running on the
node that you're stopping or putting into standby mode. Otherwise, it could
be a matter of "having to do work" versus "not having to do work."
>
> With that said, it could be that the node that's acting as DC is slower
to stop or start resources than the non-DC node, because the scheduler and
controller daemons have to do more work there. Or it could simply be that
there are non-cluster-related workload differences between the two VMs.
>
> - Reid

Surely this is only hypothetical, like you said. But if it's not, then a
look at the CIB and at the pacemaker.log from the time frame of the
failover could shed more light on the behavior in question.

>>
>> _______________________________________________
>> Manage your subscription:
>> https://lists.clusterlabs.org/mailman/listinfo/users
>>
>> ClusterLabs home: https://www.clusterlabs.org/
>>
>>
>
> --
> Regards,
>
> Reid Wahl (He/Him), RHCA
> Senior Software Maintenance Engineer, Red Hat
> CEE - Platform Support Delivery - ClusterHA
>

-- 
Regards,

Reid Wahl (He/Him), RHCA
Senior Software Maintenance Engineer, Red Hat
CEE - Platform Support Delivery - ClusterHA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20220211/b72a7978/attachment.htm>