Ooops, sorry, the behavior is not the same, you were true : with cluster-recheck-interval="90" crm resource migrate group1 node2 P300S migration is quite immediately effective then crm resource migrate group1 node1 P300S and quite 90s later, the migration occurs for the 3 groups.
OK but, is there any problem to add this check every 90s ? or does it have no bad effect on the cluster in general ? Thanks Alain De : [email protected] A : General Linux-HA mailing list <[email protected]> Date : 20/12/2011 14:26 Objet : Re: [Linux-HA] Question or problem around migration Envoyé par : [email protected] Hi I tried with cluster-recheck-interval="90" added in the cib-bootstrap-options, then same test but behavior remains the same. Alain De : Dan Frincu <[email protected]> A : General Linux-HA mailing list <[email protected]> Date : 20/12/2011 12:17 Objet : Re: [Linux-HA] Question or problem around migration Envoyé par : [email protected] Hi, On Tue, Dec 20, 2011 at 12:38 PM, <[email protected]> wrote: > Thanks, but no, I wrote in my first email that the behavior was the > same with or without lifetime, and with a lifetime of 5mn (P300S), > evenif I wait more than 5mn before requesting the second migration, > the migration is not executed, the group3 remains stalled on node2 > because of first cli-prefer on group2/node2 even if lifetime has expired. > (and by the way, I have not the warning messages you mention) > > Alain Yes, well, any time based constraint is effective if you enable cluster-recheck-interval. Guess you need to take a look at http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html-single/Pacemaker_Explained/#s-rules-recheck Regards, Dan > > > > De : Dan Frincu <[email protected]> > A : General Linux-HA mailing list <[email protected]> > Date : 20/12/2011 11:30 > Objet : Re: [Linux-HA] Question or problem around migration > Envoyé par : [email protected] > > > > Hi, > > On Tue, Dec 20, 2011 at 11:39 AM, <[email protected]> wrote: >> Hi >> >> I just would like how to manager the behavior described below : >> >> Let's say for the example that we have two nodes in Pacemaker >> configuration, and three groups >> of primitives group1, group2, and group3, and that we have colocation >> constraints such as coloc >> group2 with group1 , coloc group3 with group1. >> Now, let's say that all three groups are started on node1 >> >> Let's do the migration command : >> crm resource migrate group2 node2 P300S >> all if working fine, the 3 groups are migrated on node2 >> and we can see a cli-prefer in the cib.xml for group2 >> now if later we do the command : >> crm resource migrate group3 node1 P300S >> we can see the new cli-prefer in the cib.xml for group3 >> but the migration is never executed, it seems that it is >> the first cli-prefer on group2 that prevents the second migration to be >> executed. >> I can say that because if I so the same test but with remove of >> cli-prefer for group2 >> before executiong the crm resource migrate group3 node1 P300S, the >> migration >> of the 3 groups back to node1 is effective. >> Note that I also did the same test without lifetime parameter and it is >> the same >> behavior. >> >> So my question: >> is it an already identified (and perphas fixed) bug ? >> or is it a normal behavior and how should we manage this behavior so > that >> migration >> requests are always effective ? > > Well, after you issued the crm resource move command you might have > seen something similar to this: > > WARNING: Creating rsc_location constraint 'cli-standby-all' with a > score of -INFINITY for resource all on cluster2. > This will prevent all from running on cluster2 until the > constraint is removed using the 'crm_resource -U' command or manually > with cibadmin > This will be the case even if cluster2 is the last node in the > cluster > This message can be disabled with -Q > > Unless you specify a lifetime for the move command, then it's > permanent. Normally lifetime should be set to a value higher than the > time it takes the resources to migrate, otherwise it would remove the > constraint before all of the resources have been started on their > destination, which would cause them to migrate back, so this must be > tested, it depends on your specific scenario. > >> (I have the solution, in my example above, to do an crm resource >> unmigrate group2, >> just to remove the cli-prefer, before asking the second migration, > because > > The lifetime will help in this case. > > HTH, > Dan > >> I have >> stickyness values which avoids the group2 to move in this case, but is > it >> the >> only way and correct way to manage this behavior ?) >> >> Thanks for piece of advice. >> Alain >> >> _______________________________________________ >> Linux-HA mailing list >> [email protected] >> http://lists.linux-ha.org/mailman/listinfo/linux-ha >> See also: http://linux-ha.org/ReportingProblems > > > > -- > Dan Frincu > CCNA, RHCE > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems -- Dan Frincu CCNA, RHCE _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
