Redundant Servers (High Availability)

From Zenitel Wiki

AlphaCom icon 300px.png

The Redundant Server concept

The concept is 1:1 redundancy of exchanges. A pair of exchanges has the same configuration, only one of them is active at any time. Redundancy is provided for the IP domain only.

Software requirements

It is recommended to always use the latest AlphaCom software to get the latest features, bug fixes and security updates.

Recommended software:

Minimum software:

Note icon
  • Both servers in a HA pair must use the same software
  • Both servers in a HA pair must be of the same hardware type
  • The servers must be connected to the same network (subnet)

License handling

Regular licenses must be installed in the Configuration Master. On the Configuration Slave a Redundancy license must be installed. The system replicates the license of the Configuration Master to the Configuration Slave.

When the Configuration Slave becomes operational, the presence of the Redundancy license enables use of the replicated primary license. However, the redundancy license limits the number of station-like-licenses that can be overtaken. Four levels of the redundancy license is offered, allowing takeover of 36, 138, 276 or 552 station-like-licenses. Station-like-licenses are the sum of IP-station, SIP-station, IP-ARIO or SoftClient licenses.

For test and demonstrations one can use the free license period. In general there must either be a free license in both exchanges, or valid licenses in both exchanges.


The principle

Two exchanges are set up as a redundant HA pair, sharing the same configuration, including node number. One of the exchanges is the operational exchange, the other one is in standby. The standby exchange monitors the operational exchange via the IP network and sends a request for a status update every three seconds. The standby exchange will try to take over if it looses the connection to the operational exchange, or if it receive a message that the operational exchange has made a reset.

Each time the operational exchange resets, the standby exchange will take over, i.e. the exchanges will swap roles at every reset. This also applies to a "small reset" (application reset).

In addition the following behavior should be noted:

  • When Configuration Master is operational and looses network connection or power, the Standby server takes over.
  • The standby will then remain in control as Operational server until it looses network connection, power or a configuration change is made to the Configuration Master.

"Configuration change" includes:

  • Uploading AlphaPro database
  • User changing DAK keys using 784*
  • Changing IP Station Noise Level from Station Web interface
  • Executing event with the commands:
- $SNV
- $VOL*
- $GRM*
- $SSC*
* These commands does not cause an immediate switch from standby to operational, because it is not immediately written to the Flash memory. 
This is to preserve the longevity of the Flash memory its self. When a change is made, a 4 hour timer is started. At timeout the changes are written to the Flash memory. 
When doing a software reset, the changed will be written to flash immediately.

The delay can be disabled by setting ex_profile.glob_const.flash_sync_level = 1 in the NVRAM. 
This is not recommended. Please consult Alphasupport if wanted/needed.

It must be considered that events changing the configuration using commands such as $GRM and $SSC can cause confusion for the users, if the Standby server is the operational at the time. Configuration changes when the Standby server is operational is not synchronized with the Master server and all changes are therefore lost when the Master becomes operational again.

The network interface

The network interfaces of the exchange is configured in the standard way with separate static IP addresses. The static addresses are used for maintenance, AlphaPro and AlphaWeb. The operational address is an additional IP address, shared by the exchanges in the pair. Only one of them is active on that address at any time. All operational devices, like stations, SIP devices, other AlphaCom node, must be set up to connect to the operational address.

  • The operational address can be bound to eth0 or eth1.
  • There must be configured a static IP address on the interface which will host operational address.
  • The operational address must be within the subnet address range defined for the interface.
  • A HA pair using only one ethernet port each will need 3 IP addresses.
  • A HA pair using both ethernet ports will need 5 IP addresses.

The intercom application on the standby exchange is running, but no stations will register on it because the operational IP address is used by the operational exchange. If a operational exchange fails, the the standby exchange takes the operational IP address used by the failed exchange. Stations will reconnect, and thus register with the new exchange.

Distribution of configuration

One of the exchanges in the pair is designated as Configuration Master. AlphaPro updates must be sent to the Configuration Master. The other exchange is automatically updated with copy of the configuration from the Configuration Master. The Configuration Master checks every 15 seconds if the configuration has been changed. If changed, the standby exchange is notified, and it will fetch the configuration file via HTTP (port 80) or HTTPS (port 443, available as from ICX-AlphaCom software The operational exchange updates the standby exchange with copy of the SIP registration database (because SIP registration times may be as long as an hour).

Synchronization of State Data

Not all state data is synchronized between the exchanges.

The following state data is synchronized between the IP HA AlphaComs (from AMC

Other state data like mail queue, program selection and Simplex conference selection is not synchronized, and will be cleared when switching over to the standby exchange.

UDD's (User Define Data) are not synchronized.

Concepts and abbreviations

  • HA: High Availability
  • HA pair: A pair of exchanges, where one is operational, and the other is in standby with the same configuration.
  • Configuration Master (Primary Server): The exchange in a HA pair that has the configuration as programmed from AlphaPro. The Configuration master role is permanently assigned by AlphaWeb configuration. This role is fixed to a physical exchange.
  • Configuration slave (Secondary Server): The exchange in a HA pair that fetches the configuration from the Configuration master. This role is fixed to a physical exchange.
  • Operational IP address: A common IP address for a HA pair that stations and SIP devices connect to. The Operational IP Address is bound to the currently Operational exchange.
  • Operational exchange: The exchange which is currently using the operational IP address and which is “working”. This role is not fixed to a physical exchange.
  • Standby exchange: The exchange which currently is not operational. Its not using the Operational IP Address. This role is not fixed to a physical exchange.
  • Operational interface: The ethernet interface which the Operational IP address is bound to, eth0/eth1.

Configuration Example

IP-HA - Configuration example
  • Install latest AlphaSys package on both exchanges.
  • On Exchange A AlphaWeb, in SystemConfiguration/Interfaces, set eth0 to netmask
  • On Exchange B AlphaWeb, in SystemConfiguration/Interfaces, set eth0 to netmask
  • On Exchange A AlphaWeb, install licenses for the features you want.
  • On Exchange B AlphaWeb, install Redundancy License.
  • On both exchanges AlphaWeb, make sure HTTP (port 80) is allowed in the firewall for Eth0
  • On Exchange A AlphaWeb, in SystemConfiguration/HighAvailibility, click 'Create HA config', then
    • Operating interface : npe_eth0
    • Is configuration master : check
    • Peer exchange name : whatever
    • Operational IP address:
    • Peer maintainance IP address:
    • Save

  • On Exchange B AlphaWeb, in SystemConfiguration/HighAvalibiltiy, click 'Create HA config', then
    • Operating interface : npe_eth0
    • Is configuration master : uncheck
    • Peer exchange name : whatever
    • Operational IP address:
    • Peer maintainance IP address:
    • Save

In AlphaPro set up the exchange database under the System tab as follows:

  • Eth0 is (operational address), check AlphaNet
  • Eth1 is (config master), uncheck AlphaNet
  • Set AlphaPro to connect Eth1 address (
  • Program all IP stations, SIP stations and other AlphaComs to access address
Note icon
  • If the "Read User" password in System Configuration > User Management is changed, you must also change the password corrrespondingly in System Configuration > High Availability.
  • The Configuration Slave cannot be accessed from AlphaPro. This is by design to prevent misconfiguration. The access restriction is linked to the precense of Redundancy license.

Optional - Set Configuration Master to always be the operational server

If you want the Configuration Master to always be the operational server when it is up, you can control this by event handler in this way.

In AlphaPro, Exchange & System > Events, Insert a new event using Event Type 27, Subevent 231, When Change To = ON:


If %syse(230)



If %op(%syse(232),=,0)




  • 231 ON = The link to the other server is up again.
  • 230 ON = I am in standby, -> do not reset.
  • 232 OFF = I am the slave, so do a reset.
Configuration Master set to always be the operational server

Test and maintenance

Forcing a takeover can simply be done by doing 'small reset' of the operational exchange, or by disconnecting the ethernet cable from the operational exchange.

Status display on AlphaWeb (Under System Configuration/High Availability tab):

  • Haipd SW version: shows the current High Availability IP Daemon version
  • Exchange ExchA: This is configuraton Master
  • HA State: operational or standby
  • Connected to ExchB IP address since: shows the time and date since the two exchanges were paired
  • Downloaded /api/haipd/sipd_reg.apkg: shows when the configuration in ExchB was last updated.

Syslog messages:

  • Error message if 'NVRAM version' do not match
  • Warning message when takeover takes place.
  • Error message if contact with peer is lost for 6 seconds

Error Reporting and Monitoring:

Related articles