Vladimir,
Hi, guys
We have problems with corosync 1.4.x (1.4.6 and 1.4.7).
This is the scenario:
We have 3-node cluster:
node-1 (10.108.2.3),node-2(10.108.2.4),node-3(10.108.2.5) in UDPU mode.
We shut down the interface used for cluster communication on one of the
nodes by issuing `ifdown eth2` command on node-1.
yes. This is known problem. Actually, there is a patch for corosync 2.x,
but it's not yet reviewed and not yet backported for flatiron.
Just don't do ifdown or use NM in non server mode (does ifdown on cable
unplug).
If you need to test failover ether block trafic on switch, unplug
network cable (without NM or with NM but it had to be in server mode) or
block traffic via iptables (but carefully, you have to block everything
but not localhost...)
Regards,
Honza
node-2 and node-3 find this and understand that node-1 left the cluster.
runtime.totem.pg.mrp.srp.members.67267594.ip=r(0) ip(10.108.2.4)
runtime.totem.pg.mrp.srp.members.67267594.join_count=1
runtime.totem.pg.mrp.srp.members.67267594.status=joined
runtime.totem.pg.mrp.srp.members.84044810.ip=r(0) ip(10.108.2.5)
runtime.totem.pg.mrp.srp.members.84044810.join_count=2
runtime.totem.pg.mrp.srp.members.84044810.status=joined
runtime.totem.pg.mrp.srp.members.50490378.ip=r(0) ip(10.108.2.3)
runtime.totem.pg.mrp.srp.members.50490378.join_count=1
runtime.totem.pg.mrp.srp.members.50490378.status=left
But node-1 does not get it and thinks that node-2 and node-3 are still
online:
runtime.totem.pg.mrp.srp.firewall_enabled_or_nic_failure=1
runtime.totem.pg.mrp.srp.members.50490378.ip=r(0) ip(10.108.2.3)
runtime.totem.pg.mrp.srp.members.50490378.join_count=1
runtime.totem.pg.mrp.srp.members.50490378.status=joined
runtime.totem.pg.mrp.srp.members.67267594.ip=r(0) ip(10.108.2.4)
runtime.totem.pg.mrp.srp.members.67267594.join_count=1
runtime.totem.pg.mrp.srp.members.67267594.status=joined
runtime.totem.pg.mrp.srp.members.84044810.ip=r(0) ip(10.108.2.5)
runtime.totem.pg.mrp.srp.members.84044810.join_count=1
runtime.totem.pg.mrp.srp.members.84044810.status=joined
runtime.blackbox.dump_flight_data=no
runtime.blackbox.dump_state=no
In node-1 logs I see the following:
2014-08-13T15:46:18.848234+01:00 warning: [MAIN ] Totem is unable to
form a cluster because of an operating system or network fault. The most
common cause of this message is that the local firewall is configured
improperly.
2014-08-13T15:46:18.866365+01:00 debug: [TOTEM ] sendmsg(mcast) failed
(non-critical): Invalid argument
(22)
2014-08-13T15:46:18.866799+01:00 debug: [TOTEM ] sendmsg(mcast) failed
(non-critical): Invalid argument
(22)
2014-08-13T15:46:18.866799+01:00 debug: [TOTEM ] sendmsg(mcast) failed
(non-critical): Invalid argument
(22)
2014-08-13T15:46:18.866799+01:00 debug: [TOTEM ] sendmsg(mcast) failed
(non-critical): Invalid argument
(22)
2014-08-13T15:46:18.866799+01:00 debug: [TOTEM ] sendmsg(mcast) failed
(non-critical): Invalid argument
(22)
2014-08-13T15:46:18.866799+01:00 debug: [TOTEM ] sendmsg(mcast) failed
(non-critical): Invalid argument
(22)
2014-08-13T15:46:18.935539+01:00 debug: [TOTEM ] sendmsg(mcast) failed
(non-critical): Invalid argument
(22)
2014-08-13T15:46:18.935932+01:00 debug: [TOTEM ] sendmsg(mcast) failed
(non-critical): Invalid argument
(22)
2014-08-13T15:46:18.935932+01:00 debug: [TOTEM ] sendmsg(mcast) failed
(non-critical): Invalid argument
(22)
2014-08-13T15:46:18.935932+01:00 debug: [TOTEM ] sendmsg(mcast) failed
(non-critical): Invalid argument
(22)
2014-08-13T15:46:18.935932+01:00 debug: [TOTEM ] sendmsg(mcast) failed
(non-critical): Invalid argument
(22)
I am pretty sure that this is the bug as corosync should detect ring
failure and mark dead nodes as dead on both sides.
Can you help me fix it or provide with the clue where to look for the fix?
_______________________________________________
discuss mailing list
[email protected]
http://lists.corosync.org/mailman/listinfo/discuss
_______________________________________________
discuss mailing list
[email protected]
http://lists.corosync.org/mailman/listinfo/discuss
