Is there any particular reason your mail client is incapable of handling threads? It's quite annoying.
On Wed, Aug 6, 2008 at 15:08, Itay Donenhirsch <[EMAIL PROTECTED]> wrote: >> Date: Wed, 6 Aug 2008 13:03:10 +0200 >> From: "Andrew Beekhof" <[EMAIL PROTECTED]> >> >> As far as the cluster is concerned, the desire for a resource to stay >> where it is is outweighed by the negative colocation constraint saying >> that it cant. >> The order in which resources are allocated depends on a) the order >> they occur in the configuration, b) their priority and c) how the >> colocation constraints are set up. >> >> Eg. >> <rsc_colocation to="Gha2" score="-INFINITY" from="Gha1" >> id="CLGha1Gha2"/> >> Implies that Gha2 must be allocated first (so that we know where >> _not_ to put Gha1) >> > > So if I understand correctly, there is no way using rsc_colocation and > being perfectly symmetric in a symmetric cluster? Well you can, but the behavior will be as you saw. > I can't use colocation constraint if I want to make the cluster fully > symmetric with minimum number of resources migrations on fail-over? correct, if you don't specify any rsc_location constraints > How can I make n groups never colocate with each other and still keep > minimum number of migrations on fail-over? clone the group, since they're all the same. you may need to tweak the ip addr resource so that it adds the clone instance to a base address though (so that each node gets a different ip as it does now) > Thanks > > >> On Mon, Aug 4, 2008 at 21:39, Itay Donenhirsch <[EMAIL PROTECTED]> wrote: >>>> Date: Mon, 4 Aug 2008 14:10:23 +0200 >>>> From: "Andrew Beekhof" <[EMAIL PROTECTED]> >>>> Subject: Re: [Linux-HA] nodes failover order >>>> >>>> can you repost your current configuration? >>> >>> Sure thing. See attached file generated by hb_report. >>> >>>> >>>> On Mon, Jul 28, 2008 at 14:01, Itay Donenhirsch <[EMAIL PROTECTED]> wrote: >>>>>> From: "Andrew Beekhof" <[EMAIL PROTECTED]> >>>>> >>>>>> On Mon, Jul 28, 2008 at 10:43, Itay Donenhirsch <[EMAIL PROTECTED]> >>>>>> wrote: >>>>>>> First of all, thanks for the speedy reply. >>>>>>> >>>>>>>> From: "Andrew Beekhof" <[EMAIL PROTECTED]> >>>>>>>> >>>>>>>> On Sun, Jul 27, 2008 at 15:21, Itay Donenhirsch <[EMAIL PROTECTED]> >>>>>>>> wrote: >>>>>>>> > Hi all, >>>>>>>> > I have a weird problem: >>>>>>>> > >>>>>>>> > There are 4 nodes: ha1 ha2 ha3 ha4 >>>>>>>> > There are 3 resource groups: Gha1 Gha2 Gha3 >>>>>>>> > The cluster is symmetric. >>>>>>>> > Upon startup - Gha1 lives on ha2, Gha2 lives on ha3 and Gha3 lives >>>>>>>> > on ha4. >>>>>>>> > >>>>>>>> > I do a 'service heartbeat stop' on ha3. I expected to see Gha2 >>>>>>>> > migrate from >>>>>>>> > ha3 to ha1 but instead I get that Gha2 migrates to ha2 and Gha1 >>>>>>>> > migrates to >>>>>>>> > ha1. Why is that? >>>>>>>> >>>>>>>> Because you didnt tell it you cared. >>>>>>> >>>>>>> I don't think you understood me correctly, maybe I didn't make myself >>>>>>> clear enough, sorry. >>>>>>> I don't want the resources to fail in a specific order, just in such a >>>>>>> way that will not make non-failed resources switch nodes. >>>>>>> I don't care which node gets the failed resource as long as it will be >>>>>>> done in the minimal number of fail-overs. >>>>>>> It seems to me that it should have worked using symmetric cluster and >>>>>>> no location constraints at all. >>>>>> >>>>>> default-resource-stickiness >>>>>> >>>>> >>>>> I'm sorry but I don't get it. My default-resource-stickiness is >>>>> INFINITY. If I understand correctly it says how much the resource >>>>> "wants" to stay where it is upon fail-back. Here my problem is that a >>>>> few resources change nodes. What am I missing? >>>>> >>>>> In the document you refereed me to there is exactly one line about >>>>> default-resource-stickiness: "How much do resources prefer to stay >>>>> where they are? Used when... ". In my case "where they are" is not >>>>> relevant because they all move to places they never been to... >>>>> >>>>> But don't I seem to understand? >>>>> >>>>> Thanks >>>>> Itay > _______________________________________________ > 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
