Home Forums HAast (High Availability for Asterisk) General Which peers takes over when cluster reassembles

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • Avatar photoCustomer Inquiry
    Participant
    Post count: 203

    We recently lost the link between our primary data center and backup data center (we keep one PBX in each data center). HAAst responded correctly and both peers tried to take over, then when the link was restored one of the peers automatically demoted to standby.

    However, the PBX in the primary data center demoted, leaving the PBX in the backup data center active. Why? Shouldn’t the PBX in the primary data center have stayed active?

    Avatar photoTelium Support Group
    Participant
    Post count: 265

    When the cluster reassembles HAAst will discover 2 peers active (called ‘dual-active contention’). HAAst will then try to pick the peer with the lowest likelihood of long-term success (probability of staying active) and demote it. The determination of which peer is least likely to succeed considers:

    • Which peer caused the previous failover
    • How many failures has each peer had
    • How long has each peer been running
    • What was the last health score of each peer
    • And more…

    This works well when the peers are configured as equals (primary/primary), which implies that the cluster would be happy with either peer running. However, when the peers are not configured as equals (primary/backup), the determination of which peer should demote may result in the backup server remaining active. This describes the situation you encountered, and this is normal behavior (by design).

    As of version 2.3.2.14 the administrator can override the demotion decision, ignoring the criteria listed above. If the ‘autodemote’ key is set to true in the [backuprole] stanza of either peer, then HAAst will always demote that peer.

    Avatar photoCustomer Inquiry
    Participant
    Post count: 203

    We had a similar situation where both peers were handling calls (when our two data centers lost contact). Upon cluster re-assembly HAAst chose to demote the peer with more active calls; isn’t that backwards?

    Avatar photoTelium Support Group
    Participant
    Post count: 265

    When the peers are in a state of dual-active contention one of the peers is considered improperly active (invalid state). In other words, it should not be processing calls at all. Usually trunks (E1/T1/SIP/IAX/etc) are forced to one peer or the other which means one peer will not be getting (more) calls. If your configuration allows both peers to handle calls simultaneous then you are in the minority (this is not typical).

    For this reason the number of active calls is not a criteria in determining which peer to demote.

Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.