29.03.2012 10:07, Andrew Beekhof wrote: > On Thu, Mar 29, 2012 at 5:43 PM, Vladislav Bogdanov > <bub...@hoster-ok.com> wrote: >> 29.03.2012 09:35, Andrew Beekhof wrote: >>> On Thu, Mar 29, 2012 at 5:28 PM, Vladislav Bogdanov >>> <bub...@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@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@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@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@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