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

Vladislav Bogdanov bubble at hoster-ok.com
Wed Apr 4 07:39:53 UTC 2012


04.04.2012 02:12, Andrew Beekhof wrote:
> On Fri, Mar 30, 2012 at 7:10 PM, Florian Haas <florian at hastexo.com> wrote:
>> On Thu, Mar 29, 2012 at 8:35 AM, Andrew Beekhof <andrew at beekhof.net> 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?
>>
>> No. Few things are always true. :) However, see below.
>>
>>> 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.
>>
>> I tend to be with Vladislav on this one. The thing that most people
>> would expect from a "live migration" is that it's interruption free.
>> And what allow-migrate was first implemented for (iirc), live
>> migrations for Xen, does fulfill that expectation. Same thing is true
>> for live migrations in libvirt/KVM, and I think anyone would expect
>> essentially the same thing from checkpoint/restore migrations where
>> they're available.
>>
>> So I guess it's reasonable to assume that if one resource migrates,
>> dependent resources need not be restarted.
> 
> Ok, could someone file a bug requesting the new behaviour please?

cl#5055

> 
>> But since Pacemaker now
>> does restart them, you might need to figure out a way to preserve the
>> existing functionality for users who rely on that. Not sure if any do,
>> though.
>>
>> Cheers,
>> Florian
>>
>> --
>> Need help with High Availability?
>> http://www.hastexo.com/now
>>
>> _______________________________________________
>> 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