Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 4 subscribers
  • Views 8634 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Flapping HA 8.203 (VMware vSphere)

gartoffel
Hi there!

Last weekend, I migrated part of our setup to an ESXi5 virtualization solution. We used two ASG 220 in HA-failover mode before to achieve the exact same goal: a high-availability VPN gateway.
Since this migration, I experience some strange behavior with the HA system. To provide you with a bit more insight, here are parts of todays HA-logs: 

2011:12:12-06:03:38 vpn-1 ha_daemon[6169]: id="38A1" severity="warn" sys="System" sub="ha" name="Lost heartbeat message from node 2! Expected 29082 but got 29083"

2011:12:12-06:05:44 vpn-1 ha_daemon[6169]: id="38A1" severity="warn" sys="System" sub="ha" name="Lost heartbeat message from node 2! Expected 29207 but got 29208"

2011:12:12-06:05:56 vpn-2 ha_proxy[32048]: Initializing tinyproxy ...

2011:12:12-06:05:56 vpn-2 ha_proxy[32048]: Reloading config file

2011:12:12-06:05:56 vpn-2 ha_proxy[32048]: Listening on IP 0.0.0.0

2011:12:12-06:05:56 vpn-2 ha_proxy[32048]: Setting "Via" header to 'Astaro HA Proxy'

2011:12:12-06:05:56 vpn-2 ha_proxy[32048]: Adding Port [443] to the list allowed by CONNECT

2011:12:12-06:05:56 vpn-2 ha_proxy[32048]: Now running as group "nogroup".

2011:12:12-06:05:56 vpn-2 ha_proxy[32048]: Now running as user "nobody".

2011:12:12-06:05:56 vpn-2 ha_proxy[32051]: Creating child number 1 of 1 ...

2011:12:12-06:05:56 vpn-2 ha_proxy[32051]: Finished creating all children.

2011:12:12-06:05:56 vpn-2 ha_proxy[32051]: Setting the various signals.

2011:12:12-06:05:56 vpn-2 ha_proxy[32051]: Starting main loop. Accepting connections.

2011:12:12-06:05:56 vpn-2 ha_daemon[6211]: id="38A1" severity="warn" sys="System" sub="ha" name="Another master around!"

2011:12:12-06:05:56 vpn-2 ha_daemon[6211]: id="38A0" severity="info" sys="System" sub="ha" name="Node 1 joined with version 8.203"

2011:12:12-06:05:56 vpn-2 ha_daemon[6211]: id="38C0" severity="info" sys="System" sub="ha" name="Node 1 is alive!"

2011:12:12-06:05:56 vpn-2 ha_daemon[6211]: id="38A0" severity="info" sys="System" sub="ha" name="Node 1 changed state: DEAD -> ACTIVE"

2011:12:12-06:05:56 vpn-2 ha_daemon[6211]: id="38A0" severity="info" sys="System" sub="ha" name="Node 1 changed mode: SLAVE -> MASTER"

2011:12:12-06:05:56 vpn-2 ha_daemon[6211]: id="38A1" severity="warn" sys="System" sub="ha" name="Received backup heartbeats from master node!"

2011:12:12-06:05:57 vpn-1 ha_daemon[6169]: id="38A1" severity="warn" sys="System" sub="ha" name="Another master around!"

2011:12:12-06:05:57 vpn-1 ha_daemon[6169]: id="38A1" severity="warn" sys="System" sub="ha" name="Lost heartbeat message from node 2! Expected 29215 but got 29221"

2011:12:12-06:05:57 vpn-1 ha_daemon[6169]: id="38A0" severity="info" sys="System" sub="ha" name="Node 2 changed mode: SLAVE -> MASTER"

2011:12:12-06:05:57 vpn-1 ha_daemon[6169]: id="38A0" severity="info" sys="System" sub="ha" name="Resending gratuitous arp"

2011:12:12-06:05:57 vpn-1 ha_daemon[6169]: id="38A1" severity="warn" sys="System" sub="ha" name="Received backup heartbeats from master node!"

2011:12:12-06:05:57 vpn-2 ha_daemon[6211]: id="38A1" severity="warn" sys="System" sub="ha" name="Another master around!"

2011:12:12-06:05:57 vpn-2 ha_daemon[6211]: id="38Bb" severity="info" sys="System" sub="ha" name="Going slave mode in favour of node 1 (-29303 sec)"

2011:12:12-06:05:57 vpn-2 ha_daemon[6211]: id="38B1" severity="info" sys="System" sub="ha" name="Switching to Slave mode"

2011:12:12-06:05:57 vpn-2 ha_daemon[6211]: id="38A0" severity="info" sys="System" sub="ha" name="cluster mode: set master id to 1"

2011:12:12-06:05:58 vpn-2 slon_control[6358]: Killing slon pop3 [8753]

2011:12:12-06:05:58 vpn-1 ha_daemon[6169]: id="38A1" severity="warn" sys="System" sub="ha" name="Another master around!"

2011:12:12-06:05:58 vpn-1 ha_daemon[6169]: id="38A0" severity="info" sys="System" sub="ha" name="Resending gratuitous arp"

2011:12:12-06:05:58 vpn-1 ha_daemon[6169]: id="38A0" severity="info" sys="System" sub="ha" name="Activating sync process for database on node 2"

2011:12:12-06:05:59 vpn-1 ha_daemon[6169]: id="38A0" severity="info" sys="System" sub="ha" name="Node 2 changed mode: MASTER -> SLAVE"

2011:12:12-06:06:01 vpn-1 ha_daemon[6169]: id="38A1" severity="warn" sys="System" sub="ha" name="Received no backup heartbeats from master node!"

2011:12:12-06:06:02 vpn-2 ha_daemon[6211]: id="38A1" severity="warn" sys="System" sub="ha" name="Lost heartbeat message from node 1! Expected 30373 but got 30374"

2011:12:12-06:06:02 vpn-2 slon_control[6358]: Killing slon epp [8754]

2011:12:12-06:06:02 vpn-2 ha_daemon[6211]: id="38A0" severity="info" sys="System" sub="ha" name="Reading cluster configuration"

2011:12:12-06:06:02 vpn-2 ha_proxy[32051]: Shutting down.

2011:12:12-06:06:02 vpn-2 ha_daemon[6211]: id="38A1" severity="warn" sys="System" sub="ha" name="Received backup heartbeats from master node!"

2011:12:12-06:06:04 vpn-2 slon_control[6358]: Starting controlled switchover from Node 1 to 2

2011:12:12-06:06:04 vpn-2 slon_control[6358]: Slonik error, process exited with value 255

2011:12:12-06:06:04 vpn-2 slon_control[6358]: Starting controlled switchover from Node 1 to 2

2011:12:12-06:06:04 vpn-2 slon_control[6358]: Slonik error, process exited with value 255

2011:12:12-06:06:04 vpn-2 slon_control[6358]: Starting controlled switchover from Node 1 to 2

2011:12:12-06:06:04 vpn-2 slon_control[6358]: Slonik error, process exited with value 255

2011:12:12-06:06:04 vpn-2 slon_control[6358]: Started slon process 32671 for reporting

2011:12:12-06:06:04 vpn-2 slon_control[6358]: Started slon process 32672 for pop3

2011:12:12-06:06:04 vpn-2 slon_control[6358]: Started slon process 32673 for epp

2011:12:12-06:06:05 vpn-2 slon_control[6358]: Set mode to SLAVE

2011:12:12-06:06:05 vpn-2 ha_daemon[6211]: id="38A0" severity="info" sys="System" sub="ha" name="Deactivating sync process for database on node 1"

2011:12:12-06:06:05 vpn-2 slon_control[6358]: Skipping slony cleanup for reporting

2011:12:12-06:06:05 vpn-2 slon_control[6358]: Skipping slony cleanup for pop3

2011:12:12-06:06:05 vpn-2 slon_control[6358]: Skipping slony cleanup for epp

2011:12:12-06:06:10 vpn-1 ha_daemon[6169]: id="38C1" severity="info" sys="System" sub="ha" name="Node 2 is dead, received no heart beats!"

2011:12:12-06:06:14 vpn-1 ha_daemon[6169]: id="38A0" severity="info" sys="System" sub="ha" name="Node 2 joined with version 8.203"

2011:12:12-06:06:14 vpn-1 ha_daemon[6169]: id="38C0" severity="info" sys="System" sub="ha" name="Node 2 is alive!"

2011:12:12-06:06:14 vpn-1 ha_daemon[6169]: id="38A0" severity="info" sys="System" sub="ha" name="Node 2 changed state: DEAD -> ACTIVE"

2011:12:12-06:06:15 vpn-2 ha_daemon[6211]: id="38A1" severity="warn" sys="System" sub="ha" name="Lost heartbeat message from node 1! Expected 30381 but got 30387"

2011:12:12-06:06:34 vpn-2 ha_daemon[6211]: id="38A0" severity="info" sys="System" sub="ha" name="Monitoring interfaces for link beat: eth0 eth1 eth3 "

2011:12:12-06:11:30 vpn-1 slon_control[6309]: Initial synchronization for node 2 finished!

2011:12:12-06:11:30 vpn-1 ha_daemon[6169]: id="38A0" severity="info" sys="System" sub="ha" name="Deactivating sync process for database on node 2"


If I am not misinterpreting something, the master node sometimes fails to receive a heartbeat signal from the slave, even though they are directly connected with a vSwitch (port: eth2). Has anyone else had these issues with a virtual ASG on the same physical host?

I am thinking about using the "cc set ha advanced virtual_mac 0" trick, but I fear that when there is no "clean" failover, the two nodes will announce themselves as default gateway with two different MAC addresses. And that would mess up a lot of things...

Any idea how to fix that? Thanks for helping me out.

Cheers,
Manuel


This thread was automatically locked due to age.
Parents
  • 0
    No, I meant that its very unlikely that virtual_mac is causing that issue. Deactivating however
    should not do harm either. After a Master/Master situations and takeover gratuitous ARPs are send, so clients should send packets to the right Master node.

    The HA dead_time should already be increased to 10 seconds on virtual ASG systems.
    Can you check whats the current value on your system?

    By checking your log file again: There are a couple of "Lost heartbeat" messages:
    Three times 1 packet and two times 6 packets. How many times does this happen?
    Any backups running during that time?

    Cheers
     Ulrich
Reply
  • 0
    No, I meant that its very unlikely that virtual_mac is causing that issue. Deactivating however
    should not do harm either. After a Master/Master situations and takeover gratuitous ARPs are send, so clients should send packets to the right Master node.

    The HA dead_time should already be increased to 10 seconds on virtual ASG systems.
    Can you check whats the current value on your system?

    By checking your log file again: There are a couple of "Lost heartbeat" messages:
    Three times 1 packet and two times 6 packets. How many times does this happen?
    Any backups running during that time?

    Cheers
     Ulrich
Children
  • 0 in reply to da_merlin
    Hi Ulrich

    Sorry for the delay and thanks for your efforts.

    No, I meant that its very unlikely that virtual_mac is causing that issue. Deactivating however
    should not do harm either. After a Master/Master situations and takeover gratuitous ARPs are send, so clients should send packets to the right Master node.

    OK, disabled the virtual_mac last night and started a forced failover without any issues. Still, my concern remains that an "unclean" failover might cause some problems for the connected guests. But I can live with that for now.

    The HA dead_time should already be increased to 10 seconds on virtual ASG systems.
    Can you check whats the current value on your system?

    We didn't install the VMware version, therefore the dead_time value was set to 3 seconds. In the meantime, I increased it to 10 seconds. Anything else I should know? [;)]

    Any backups running during that time?

    Yes, your guess was right and the sysadmin guys confirmed it this morning: Unfortunately, I was unaware of the four backup jobs that are automatically scheduled for any new VM on the system and therefore didn't suspect anything.
    After having confirmation I can now reproduce the instabilities: When starting a backup job, vSphere creates a Snapshot and when it's done, it deletes the old one. These two events trigger the instabilities, because the system becomes irresponsive for a few seconds during the creation and deletion of a snapshot. Hence the loss of packets.

    With the increased dead_time I can still see that packets get lost, but no failover occurs, which is great.

    As always, I appreciate your help and look forward to test the BGP beta on my new hardware (which should in fact be delivered any second [:)]). Thank you very much Ulrich!

    Cheers,
    Manuel
Unfiltered HTML