Restrictions and limitations of 1+1 High Availability clusters

Last Updated : Jun 18, 2021 |

1+1 High Availability clusters have the following restrictions and limitations:

  • High Availability functionality is limited to specific applications. To determine if you can configure an application with High Availability, see adopting product documentation. Do not configure High Availability unless the adopting product documentation indicates it is supported.

  • High availability is not supported in public cloud computing platforms such as Amazon Web Services.

  • High Availability can be configured only in 1+1 configuration. N+1 Load Sharing clustering and 1+1 High Availability clustering are two different configuration options that you cannot combine.

  • High Availability is available only if the servers are installed on the Linux® operating system.

  • High Availability peer servers must be on the same subnet and the subnet must have Layer 2 network redundancy.

  • High Availability servers must be configured with network interface bonding for increased performance and network interface redundancy.

  • Splitting an 1+1 High Availability cluster across two data centers is not a recommended configuration. A stretch layer 2 LAN is required and round trip latency must be less than 50 milliseconds.

  • IPv4 SIP signaling and media processing must use same IPv4 host address.

  • If IPv6 is used, SIP signaling and media processing must use same IPv6 host address.

  • If IPv6 is used, IPv4 and IPv6 host addresses must be on the same network interface.

  • WebRTC and video media sessions are not preserved after failover.

  • Core file generation on High Availability servers must be disabled. If not, end-users experience temporary voice loss or loss of service when processes unexpectedly quit. For more information on configuring core file generation, see Installing and Updating Avaya Aura® Media Server Application on Customer Supplied Hardware and OS.

  • Both the Primary and Backup Avaya Aura® MS must use a common Network Time Protocol (NTP) server for clock synchronization.

  • After the Backup server is active, service falls back to the Primary server only when the Backup server fails. To restore the Primary server to the active state immediately, manually set the Backup server status to Failover. Select Failover from the More Actions drop-down list on EM > Element Status.