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/Pacemaker_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

Reply via email to