>>> <[email protected]> schrieb am 20.12.2011 um 14:35 in Nachricht <of8cda8ee9.357cca86-onc125796c.004a7cee-c125796c.004b2...@bull.net>: > 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 ?
It probably fills your syslog with rechecking messages... > > 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_Expla > ined/#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 > > _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
