|
Dear all, This is my first post on this list, I hope this is the right forum for it… On a router cluster I have a number of IP resources for IPv4 and IPv6 VLANs. The cluster is implemented with corosync and pacemaker on Debian Wheezy systems, with resource-agents version 1:3.9.2-5+deb7u1. The IPv4 resources are implemented by /usr/lib/ocf/resource.d/heartbeat/IPaddr2. The IPv6 resources are implemented by /usr/lib/ocf/resource.d/heartbeat/IPv6addr. When the active router dies, the resources are moved to the other node. The IPv4 address resources are activated immediately, within a few milliseconds. The IPv6 address resources however take about 7 seconds each to start.
I have investigated why this takes so long: -
first the address is assigned to the interface, -
then a check is performed to see that the address is really active. This means that max 5 pings are done, waiting 1 second after each ping, until a response is received (which happens usually after 2 seconds), -
and then 5 seconds are spent sending unsolicited advertisement packets to the neighbours. The IPv4 address only sends ARP messages after the address assignment is made, but defaults to sending them in a background task. Can anyone explain to me the design choices made here? Why does it take so long to start a IPv6 address resource? I had to increase the number of process children in corosync (responsible for starting the resources, defaults to 4) to get
all the IP addresses started in a reasonable time (say 1 second), because in the initial default configuration, starting a lot of resources is blocked while waiting for the IPv6 address resources… --
--
|
_______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
