[Pacemaker] Migration of "lower" resource causes dependent resources to restart

Vladislav Bogdanov bubble at hoster-ok.com
Thu Mar 29 07:19:39 UTC 2012


29.03.2012 10:07, Andrew Beekhof wrote:
> On Thu, Mar 29, 2012 at 5:43 PM, Vladislav Bogdanov
> <bubble at hoster-ok.com> wrote:
>> 29.03.2012 09:35, Andrew Beekhof wrote:
>>> On Thu, Mar 29, 2012 at 5:28 PM, Vladislav Bogdanov
>>> <bubble at hoster-ok.com> wrote:
>>>> Hi Andrew, all,
>>>>
>>>> Pacemaker restarts resources when resource they depend on (ordering
>>>> only, no colocation) is migrated.
>>>>
>>>> I mean that when I do crm resource migrate lustre, I get
>>>>
>>>> LogActions: Migrate lustre#011(Started lustre03-left -> lustre04-left)
>>>> LogActions: Restart mgs#011(Started lustre01-left)
>>>>
>>>> I only have one ordering constraint for these two resources:
>>>>
>>>> order mgs-after-lustre inf: lustre:start mgs:start
>>>>
>>>> This reminds me what have been with reload in a past (dependent resource
>>>> restart when "lower" resource is reloaded).
>>>>
>>>> Shouldn't this be changed? Migration usually means that service is not
>>>> interrupted...
>>>
>>> Is that strictly true?  Always?
>>
>> This probably depends on implementation.
>> With qemu live migration - yes.
> 
> So there will be no point at which, for example, pinging the VM's ip
> address fails?

Even all existing connections are preserved.
Small delays during last migration phase are still possible, but they
are minor (during around 100-200 milliseconds while context is switching
and ip is announced from another node). And packets are not lost, just
delayed a bit.

I have corosync/pacemaker udpu clusters in VMs, and even corosync is
happy when VM it runs on is migrating to another node (with some token
tuning).

> 
>> With pacemaker:Dummy (with meta allow-migrate="true") probably yes too...
>>
>>> My understanding was although A thinks the migration happens
>>> instantaneously, it is in fact more likely to be pause+migrate+resume
>>> and during that time anyone trying to talk to A during that time is
>>> going to be disappointed.
>>
>>
>>>
>>> _______________________________________________
>>> 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





More information about the Pacemaker mailing list