[ClusterLabs] What's wrong with IPsrcaddr?

[ZZ Wave]

Thank you for the idea about a bug in resource script.

...
NETWORK=`$IP2UTIL route list dev $INTERFACE scope link $PROTO match
$ipaddress|grep -m 1 -o '^[^ ]*'`
...

$NETWORK was surprisingly empty when a bug occurs, something wrong was with
$PROTO variable. Command above returns the correct route without it and
I've removed it. Now it works like a charm. Maybe it's something
Debian10-specific.

чт, 17 мар. 2022 г. в 17:46, Andrei Borzenkov <arvidjaar at gmail.com>:

> On 17.03.2022 14:14, ZZ Wave wrote:
> >> Define "network connectivity to node2".
> >
> > pacemaker instances can reach each other, I think.
>
> This is called split brain, the only way to resolve it is fencing.
>
> > In case of connectivity
> > loss (turn off network interface manually, disconnect eth cable etc), it
> > should turn off virtsrc and then virtip on active node, turn virtip on
> and
> > then virtsrc on second node, and vice-versa. IPaddr2 alone works fine
> this
> > way "out of a box", but IPsrcaddr doesn't :(
> >
>
> According to scarce logs you provided stop request for IPsrcaddr
> resource failed which is fatal. You do not use fencing so pacemaker
> blocks any further change of resource state.
>
> I cannot say whether this is resource agent bug or agent legitimately
> cannot perform stop action. Personally I would claim that if
> corresponding routing entry is not present, resource is stopped so
> failing stop request because no route entry was found sounds like a bug.
>
> > Is my setup correct for this anyway?
>
> You need to define "this". Your definition of "network connectivity"
> ("pacemaker instances can reach each other") does not match what you
> describe later. Most likely you want failover if current node does not
> some *external* connectivity.
>
> > Howtos and google give me only "just
> > add both resources to group or to colocation+order and that's all", but
> it
> > definitely doesn't work the way I expect.
> >
>
> So your expectations are wrong. You need to define more precisely what
> is network connectivity in your case and how you check for it.
>
> >> What are static IPs?
> >
> > node1 192.168.80.21/24
> > node2 192.168.80.22/24
> > floating 192.168.80.23/24
> > gw 192.168.80.1
> >
>
> I did not ask for IP addresses. I asked for your explanation what
> "static IP" means to you and how is it different from "gloating IP".
>
> >> I do not see anything wrong here.
> >
> > Let me explain. After initial setup, virtip and virtsrc successfully
> apply
> > on node1. There are both .23 alias and def route src. After a network
> > failure, there is NO default route at all on both nodes and IPsrcaddr
> > fails, as it requires default route.
> >
>
> I already explained above why IPsrcaddr was not migrated.
>
> >
> > ср, 16 мар. 2022 г. в 19:23, Andrei Borzenkov <arvidjaar at gmail.com>:
> >
> >> On 16.03.2022 12:24, ZZ Wave wrote:
> >>> Hello. I'm trying to implement floating IP with pacemaker but I can't
> >>> get IPsrcaddr to work correctly. I want a following thing - floating
> >>> IP and its route SRC is started on node1. If node1 loses network
> >>> connectivity to node2, node1 should instantly remove floating IP and
> >>> restore default route,
> >>
> >> Define "network connectivity to node2".
> >>
> >>> node2 brings these things up. And vice-versa when node1 returns.
> >>> Static IPs should be intact in any way.
> >>>
> >>
> >> What are static IPs?
> >>
> >>> What I've done:
> >>>
> >>> pcs host auth node1 node2
> >>> pcs cluster setup my_cluster node1 node2 --force
> >>> pcs cluster enable node1 node2
> >>> pcs cluster start node1 node2
> >>> pcs property set stonith-enabled=false
> >>> pcs property set no-quorum-policy=ignore
> >>> pcs resource create virtip ocf:heartbeat:IPaddr2 ip=192.168.80.23
> >>> cidr_netmask=24 op monitor interval=30s
> >>> pcs resource create virtsrc ocf:heartbeat:IPsrcaddr
> >>> ipaddress=192.168.80.23 cidr_netmask=24 op monitor interval=30
> >>> pcs constraint colocation add virtip with virtsrc
> >>> pcs constraint order virtip then virtsrc
> >>>
> >>> It sets IP and src correctly on node1 one time after this setup, but
> >>> in case of failover to node2 a havoc occurs -
> >>
> >> Havoc is not useful technical description. Explain what is wrong.
> >>
> >>> https://pastebin.com/GZMtG480
> >>>
> >>> What's wrong?
> >>
> >> You tell us. I do not see anything wrong here.
> >>
> >>> Help me please :)
> >>>
> >>>
> >>> _______________________________________________
> >>> Manage your subscription:
> >>> https://lists.clusterlabs.org/mailman/listinfo/users
> >>>
> >>> ClusterLabs home: https://www.clusterlabs.org/
> >>
> >> _______________________________________________
> >> Manage your subscription:
> >> https://lists.clusterlabs.org/mailman/listinfo/users
> >>
> >> ClusterLabs home: https://www.clusterlabs.org/
> >>
> >
> >
> > _______________________________________________
> > Manage your subscription:
> > https://lists.clusterlabs.org/mailman/listinfo/users
> >
> > ClusterLabs home: https://www.clusterlabs.org/
>
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users
>
> ClusterLabs home: https://www.clusterlabs.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20220317/026f3c0e/attachment.htm>