Hi, 21.02.2011 22:29, Florian Haas wrote: > On 02/21/2011 08:00 PM, Frederik Schüler wrote: >> Hello *, >> >> as the various ocf:*:ping[d] incarnations don't meet my specific needs, > > May I ask why and how?
I was thinking about writing something similar. I need this in a quite complex networking setup, where one 10Gb iface and bonding on two 1Gbps ifaces are both members of a STP-enabled bridge. 10G is a preferred STP path. Cluster exports iSCSI luns backed by DRBD. What I need is to prefer node which has 10G path working for such exports. pingd is unable to help here. Although for my needs simple link status is not enough, I need to look at STP information too, this RA (didn't look at code yet) should be a good starting point for me. > >> I >> wrote a small RA using ethtool to detect a network link failure, in order to >> trigger a failover. > > Well, what if the link is up but there's an upstream problem? I've > always liked how ocf:pacemaker:ping actually monitors connectivity to an > upstream IP, which covers both immediate link failure and upstream > problems. Similar to how in active/backup bonding, you can fail over > based on the status of an ARP request, rather than MII link status. Two RA's could be combined, we can have two location constraints with different attributes, no? Best, Vladislav _______________________________________________ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
