*The task was initially set as follows:* - We have a group of resources that must co-locate ( as a group ) on the same node. - This group includes web server, IP address, file system and several more specific services. - The group must run on node that has external link.
The use case is: someone plug ethernet out from the box -> LinkUp "monitor" ( that merely checks /sys/class/net/bond0/carrier file ) returns OCF_ERR_GENERIC -> fail counter for LinkUp increases -> score for LinkUp becames negative -> LinkUp fails over to other node. LinkUp has it's own stickiness/failure-stickiness set as meta-attributes and adjusted to fail over on the very first failure. During the failover: ( as I understand ) HA should call "stop" for LInkUp as soon as "monitor" returns OCF_ERR_GENERIC, right? So, I break the co-location constraint in LinkUp::stop to allow it migrate to another node but leave the webserver group unaffected until the LInkUp starts successfully on the backup node. This is intended to avoid unnecessary failover of the web server group ( it takes pretty long to start all that services ) in case we have ethernet switch failure and both nodes loose connectivity at the same moment. LinkUp "start" checks carrier on that node and returns OCF_SUCCESS if present. It creates co-location constraint for the webserver group just when it's about to return OCF_SUCCESS. The idea was that if the LinkUp has successfully started it should to attract the webserver group. Moreover, LinkUp may ping-pong between the main and backup nodes until it discovers external link on one of them. Problem: it appeared that co-location is treated by the HA PE as "start here or die" so, it tries to start the LinkUp again on the same node where it has just failed :( Just because it see co-location with INFINITY and probably apply a rule that INFINITY beats any negative score, right? So at this moment we have LinkUp that has not started on backup yet and has no positive score there and we have INFINITY constraint on the main node... That is my understanding of what's happened. Now I use a workaround : I create static preference for the webserver group from the LinkUp "start". I merely call cibadmin to update the node name in the location preference constraint for the webserver group. It works pretty good and apparently is better way to express my wishes :) Nevertheless, I would appreciate very much if you point me any source of documentation to learn more about how the PE decides about neseccary actions when the CIB changes or any other external events occur. I have already read all that could find on linux-ha.org though... So I mean I understand about score calculation, fail counters, constraints etc. I'm looking for more detailed documentation. 2009/2/2 Andrew Beekhof <[email protected]> > On Fri, Jan 30, 2009 at 15:54, Alexander Timofeev > <[email protected]> wrote: > > I have a linkup resource that can only run on node with external eth > > connection present. > > Linkup resource fails as soon as node looses external connectivity and > fails > > over to another node. > > Then it tries to start there. It starts successfully if node has external > > connection. > > I want it to attract serverIP resource to that node. > > The idea in general is that linkup tries to start on several nodes until > > either it discovers that no nodes have external link > > or finds one and then moves serverIP there. > > I create a co-location constraint from the linkup RA "start" and remove > this > > constraint from "stop". > > > > The problem is: > > linkup fails on A and fails over to B > > creates a constraint with INFINITY to co-locate with serverIP in "start", > > "start" returns OCF_SUCCES > > as soon as constraint is created HA tries to start linkup again on that > node > > where it has failed ( because serverIP is still there ), > > obviously "start" fails and I have linkup and serverIP run on B but > INFINITY > > fail counter for A and "start_on_A" in failed actions. > > So linkup will never run on A again until I clear it in LRM by > crm_resource > > -C. > > > > Does anybody know, what's the reason of such behavior and is there a > > workaround? > > I supposed that serverIP should follow the linkup when the constraint > > appears... but HA prefers to restart linkup on node where it has just > > failed. > > This looks strange for me. > > Its even stranger to us... you have an RA that creates constraints? > Do you have an ordering constraint between the ip and linkup resources? > > It might be best if you just showed us your configuration. > _______________________________________________ > 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
