[ClusterLabs] IPaddr2 RA and bonding

Tomer Azran tomer.azran at edp.co.il
Sun Aug 13 05:21:16 UTC 2017 

I created a pull request with my code:
https://github.com/ClusterLabs/pacemaker/pull/1319


-----Original Message-----
From: Ken Gaillot [mailto:kgaillot at redhat.com] 
Sent: Thursday, August 10, 2017 5:33 PM
To: users at clusterlabs.org
Subject: Re: [ClusterLabs] IPaddr2 RA and bonding

On Thu, 2017-08-10 at 11:02 +0000, Tomer Azran wrote:
> 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/ip
> speed

Nice! Feel free to open a PR against the ClusterLabs/pacemaker repository with your changes. You could make it so the user has to specify one of iface or ip, or you could have another parameter iface_from_ip=true/false and put the IP in iface.

> 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:bubble at hoster-ok.com]
> Sent: Monday, August 7, 2017 9:22 PM
> To: users at 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/i
> fspeed
> 
> 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_Explaine
> d/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:kgaillot at redhat.com]
> > Sent: Monday, August 7, 2017 7:14 PM
> > To: Cluster Labs - All topics related to open-source clustering 
> > welcomed <users at 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/Pacem
> > ak 
> > er_Explained/index.html#_moving_resources_due_to_connectivity_change
> > s
> >
> >> 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 at 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 <kgaillot at redhat.com>
> >
> >
> >
> >
> >
> > _______________________________________________
> > Users mailing list: Users at 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 at 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 at 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 at 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 <kgaillot at redhat.com>





_______________________________________________
Users mailing list: Users at 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

More information about the Users mailing list