That looks exactly what I needed - it works. I had to change the RA since I don't want to give an interface name as a parameter (it might change from server to server and I want to create a cloned resource). I changed the RA a little bit to be able to guess the interface name based on a IP address parameter. The new RA is published on my github repo: https://github.com/tomerazran/Pacemaker-Resource-Agents/blob/master/ipspeed
Just to document the solution in case anyone will need it also, I run the following setup: # pcs resource create vip ocf:heartbeat:IPaddr2 ip=192.168.1.3 op monitor interval=30 # pcs resource create vip_speed ocf:heartbeat:ipspeed ip=192.168.1.3 name=vip_speed op monitor interval=5s --clone # pcs constraint location vip rule score=-INFINITY vip_speed lt 1 or not_defined vip_speed Thank you for the support, Tomer. -----Original Message----- From: Vladislav Bogdanov [mailto:bub...@hoster-ok.com] Sent: Monday, August 7, 2017 9:22 PM To: users@clusterlabs.org Subject: Re: [ClusterLabs] IPaddr2 RA and bonding 07.08.2017 20:39, Tomer Azran wrote: > I don't want to use this approach since I don't want to be depend on pinging > to other host or couple of hosts. > Is there any other solution? > I'm thinking of writing a simple script that will take a bond down > using ifdown command when there are no slaves available and put it on > /sbin/ifdown-local For the similar purpose I wrote and use this one - https://github.com/ClusterLabs/pacemaker/blob/master/extra/resources/ifspeed It sets a node attribute on which other resources may depend via location constraint - http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/ch08.html#ch-rules It is not installed by default, and that should probably be fixed. That RA supports bonds (and bridges), and even tries to guess actual resulting bond speed based on a bond type. For load-balancing bonds like LACP (mode 4) one it uses coefficient of 0.8 (iirc) to reflect actual possible load via multiple links. > > > -----Original Message----- > From: Ken Gaillot [mailto:kgail...@redhat.com] > Sent: Monday, August 7, 2017 7:14 PM > To: Cluster Labs - All topics related to open-source clustering > welcomed <users@clusterlabs.org> > Subject: Re: [ClusterLabs] IPaddr2 RA and bonding > > On Mon, 2017-08-07 at 10:02 +0000, Tomer Azran wrote: >> Hello All, >> >> >> >> We are using CentOS 7.3 with pacemaker in order to create a cluster. >> >> Each cluster node ha a bonding interface consists of two nics. >> >> The cluster has an IPAddr2 resource configured like that: >> >> >> >> # pcs resource show cluster_vip >> >> Resource: cluster_vip (class=ocf provider=heartbeat type=IPaddr2) >> >> Attributes: ip=192.168.1.3 >> >> Operations: start interval=0s timeout=20s (cluster_vip >> -start-interval-0s) >> >> stop interval=0s timeout=20s (cluster_vip >> -stop-interval-0s) >> >> monitor interval=30s (cluster_vip >> -monitor-interval-30s) >> >> >> >> >> >> We are running tests and want to simulate a state when the network >> links are down. >> >> We are pulling both network cables from the server. >> >> >> >> The problem is that the resource is not marked as failed, and the >> faulted node keep holding it and does not fail it over to the other >> node. >> >> I think that the problem is within the bond interface. The bond >> interface is marked as UP on the OS. It even can ping itself: >> >> >> >> # ip link show >> >> 2: eno3: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc mq >> master bond1 state DOWN mode DEFAULT qlen 1000 >> >> link/ether 00:1e:67:f6:5a:8a brd ff:ff:ff:ff:ff:ff >> >> 3: eno4: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc mq >> master bond1 state DOWN mode DEFAULT qlen 1000 >> >> link/ether 00:1e:67:f6:5a:8a brd ff:ff:ff:ff:ff:ff >> >> 9: bond1: <NO-CARRIER,BROADCAST,MULTICAST,MASTER,UP> mtu 1500 qdisc >> noqueue state DOWN mode DEFAULT qlen 1000 >> >> link/ether 00:1e:67:f6:5a:8a brd ff:ff:ff:ff:ff:ff >> >> >> >> As far as I understand the IPaddr2 RA does not check the link state >> of the interface – What can be done? > > You are correct. The IP address itself *is* up, even if the link is down, and > it can be used locally on that host. > > If you want to monitor connectivity to other hosts, you have to do that > separately. The most common approach is to use the ocf:pacemaker:ping > resource. See: > > http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html-single/Pacemak > er_Explained/index.html#_moving_resources_due_to_connectivity_changes > >> BTW, I tried to find a solution on the bonding configuration which >> disables the bond when no link is up, but I didn't find any. >> >> >> >> Tomer. >> >> >> _______________________________________________ >> Users mailing list: Users@clusterlabs.org >> http://lists.clusterlabs.org/mailman/listinfo/users >> >> Project Home: http://www.clusterlabs.org Getting started: >> http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf >> Bugs: http://bugs.clusterlabs.org > > -- > Ken Gaillot <kgail...@redhat.com> > > > > > > _______________________________________________ > Users mailing list: Users@clusterlabs.org > http://lists.clusterlabs.org/mailman/listinfo/users > > Project Home: http://www.clusterlabs.org Getting started: > http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > Bugs: http://bugs.clusterlabs.org > _______________________________________________ > Users mailing list: Users@clusterlabs.org > http://lists.clusterlabs.org/mailman/listinfo/users > > Project Home: http://www.clusterlabs.org Getting started: > http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > Bugs: http://bugs.clusterlabs.org > _______________________________________________ Users mailing list: Users@clusterlabs.org http://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org _______________________________________________ Users mailing list: Users@clusterlabs.org http://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org