Actions

Redundant Servers (AlphaCom XE)

From Zenitel Wiki

AlphaCom icon 300px.png

This article describes how to configure redundant AlphaCom XE servers. For redundancy using ICX-AlphaCom servers, see Redundant_Servers_-_ICX-AlphaCom

Redundancy AlphaCom.PNG
Redundant Servers - AlphaCom XE

The Redundant Server concept

The concept is 1:1 redundancy of servers. The pair of servers has the same configuration, and only one of them is active at any time.

The High availability solution is maximizing uptime during:

  • System level failures
  • Environment-level failures (power outage, fire, earthquake, etc.)
  • Planned outage for system maintenance and upgrades


Abbreviations

  • HA: High Availability
  • HA pair: A pair of servers, where one is operational, and the other is in standby with the same configuration.
  • Primary Server (Configuration Master): The server in a HA pair that has the configuration as programmed from AlphaPro. This role is defined via the license. The role is fixed to a physical server.
  • Secondary Server (Configuration slave): The server in a HA pair that fetches the configuration from the Primary Server. This role is fixed to a physical server.
  • 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 server.
  • Operational server: The server which is currently using the operational IP address and to which the stations and devices are registered to. This role is not fixed to a physical server.
  • Standby server: The server which currently is not operational. It is not using the Operational IP Address. This role is not fixed to a physical server.
  • Operational interface: The ethernet interface which the Operational IP address is bound to, eth0 or eth1.


Software requirements

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

Recommended software:

Minimum software:


Important notes:

Note icon
  • Both servers in a HA pair must run on the same software version
  • The servers must be connected to the same network (subnet)


Licenses

Regular licenses must be installed in the Primary Server. On the Secondary Server a Redundancy license must be installed. The system replicates the license of the Primary Server to the Secondary Server.

When the Secondary Server 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 servers, or valid licenses in both servers.


Description

The principle

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

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

The network interface

The network interfaces of the server 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 servers 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 a total of 3 IP addresses.
  • A HA pair using both ethernet ports will need a total of 5 IP addresses.

The Intercom Application (AMCd) is running also while a server is in standby mode, but no stations will register to it because the operational IP address is used by the other (operational) server. If the operational server fails, the standby server will take over the operational IP address. Stations will then reconnect to the same IP address, but now to the new server.

Distribution of configuration

The Primary Server in the HA pair is designated as Configuration Master. AlphaPro updates are sent to the Primary Server. The Secondary Server will automatically be updated with copy of the configuration from the Primary Server. The Primary Server checks every 15 seconds if the configuration has been changed. If changed, the Secondary server is notified, and it will fetch and apply the configuration file via HTTP (port 80) or HTTPS (port 443). The operational server also updates the standby server with copy of the SIP registration database (because SIP registration times may be as long as an hour).


Configuration

IPHA Config AlphaCom.PNG
Redundant Servers - Configuration example

The configuration of the Redundant Server feature is done from the Web interface of the servers. This is best explained by an example. The below confiuration example is with reference to the drawing to the right.

Configure the IP address in both servers

  • In System Configuration > Interfaces configure the Ethernet port 1 of the Primary Server with IP address 10.9.8.30
  • In System Configuration > Interfaces configure the Ethernet port 1 of the Secondary Server with IP address 10.9.8.31

Install licenses

  • In System Configuration > Licensing, install the licenses.

Configure the Redundancy feature in the Primary Server

On the Primary Server go to System Configuration > High Availability, click 'Create HA config':

  • Check the flag Is Configuration Master
  • Operating interface: eth1 (10.9.8.30) (This is the local ethernet port used by this server)
  • Peer exchange name: Any descriptive text (Typically you enter the name of the other server)
  • Operational IP address: 10.9.8.32 (This is the common IP address used by both servers, and to which all stations and devices register to. Must be identical on both servers)
  • Peer maintenance IP address: 10.9.8.31 (This is the IP address of the other server)
  • Username: alpha (This is the "Read" user name as defined in System Configuration > User Management. Default is alpha/com. If the "Read" user is changed, this field must be updated accordingly)
  • Password: com (This is the "Read" password name as defined in System Configuration > User Management. Default is alpha/com. If the "Read" user is changed, this field must be updated accordingly)
  • Validate and Save

Make sure HTTP (port 80) is enabled in the Filters settings for Eth1. This port is used to exchange data between the servers.

Configure the Redundancy feature in the Secondary Server

On the Secondary Server go to System Configuration > High Availability, click 'Create HA config':

  • Uncheck the flag Is Configuration Master
  • Operating interface: eth1 (10.9.8.31) (This is the local ethernet port used by this server)
  • Peer exchange name: Any descriptive text (Typically you enter the name of the other server)
  • Operational IP address: 10.9.8.32 (This is the common IP address used by both servers, and to which all stations and devices register to. Must be identical on both servers)
  • Peer maintenance IP address: 10.9.8.30 (This is the IP address of the other server)
  • Username: alpha (This is the "Read" user name as defined in System Configuration > User Management. Default is alpha/com. If the "Read" user is changed, this field must be updated accordingly)
  • Password: com (This is the "Read" password name as defined in System Configuration > User Management. Default is alpha/com. If the "Read" user is changed, this field must be updated accordingly)
  • Validate and Save

Make sure HTTP (port 80) is enabled in the Filters settings for Eth1. This port is used to exchange data between the servers.

AlphaPro settings

In AlphaPro go to Exchange & System > System:

  • In the first IP address field enter the local IP address of the Primary Server. Enable AlphaPro to Connect to this address (here 10.9.8.30). Uncheck "AlphaNet".
  • In the second IP address field enter the Operational IP address of the HA pair. Check "AlphaNet".

(You can ignore the description in AlphaPro that the first IP address field is for Eth0 and the second field is for Eth1).

IPHA AlphaPro AC.PNG
IP settings in AlphaPro


Note icon AlphaPro cannot connect to the Secondary Server. A connection attempt will be rejected by the server.


Status information and Test

Status information

The sever in Standby mode will show this in the Web interface, System Monitoring > Node Information:

IPHA AMC Standby.PNG
Standby status is shown in the web interface


The status is also displayed in System Configuration > High Availability:

IPHA Status AMC.png
Current status displayed in System Configuration > High Availability:
  • Haipd SW version: shows the current High Availability IP Daemon version
  • Exchange peer name: The name of the other server
  • HA State: operational or standby
  • Connected to <other server> since: shows the time and date since the two servers were paired
  • Downloaded /api/haipd/amcd_conf.apkg: shows when the configuration file was last updated.
  • Downloaded /api/haipd/state_data.apkg: shows when the state data file was last updated.


Test and verification

Force takeover: The standby server can be forced to take over the operation in several ways:

  • Small Reset or Reboot from the Web interface of the Operational Server
  • Disconnect the ethernet cable on the Operational Server
  • Power off the Operational Server

Observe takeover: Observe that the standby server changes state to Operational and that:

  • Status changes in the web interface of the servers

Verify that:

Logging:

Synchronization of Data - Additional info

Configuration from AlphaPro

The configuration data sent from AlphaPro is written to the working (RAM) memory of the Primary Server. When the update is finished, the configuration data is copied to the flash memory for permanant storage. The secondary server will be notified about the change, and will fetch and apply the new configuration data.

After system reset or startup the working RAM memory is cleared. Configuration data is now loaded to the working memory from the flash.

Other configuration

Some configuration can also be modified by the users:

  • Programming DAK keys on the station - code 784
  • Changing the volume settings on the station

And some configuration can be modified by data commands, typically used within the Event Handler:

  • $VOL - Modify station volume
  • $GRM - Include/exclude a station from group
  • $SSC - Modify the CoS (Class of Service) for a station
  • $SNV - Modify values in the working RAM memory

These configuration changes are written to the working memory. However they are not immediately copied to the flash memory. This is to preserve the longevity of the flash memory itself. When a change is made, a 4 hour timer is started. At timeout the changes are written to the flash memory, and the configuration is syncronized with the Secondary server. When doing a software reset, any pending changes will be copied to flash before the reset is performed. (No copying if sudden power reset).

Note icon
  • The syncronization is from Primary Server to Secondary Server only, not in the other direction.
  • Configuration changes done when the Secondary Server is operational will not be synchronized with the Primary server, hence any changes will be lost when the Primary becomes operational again.
  • If users or events are changing configuration data, it should be considered to configure the system in such a way that the Primary Server is always operational when the HA pair is running.


State data

State data is stored in a dedicated battery backed up RAM memory. State data is temporarily user data such as:

State data is not synchronized between the servers.

Note icon If it is important to preserve the state data, it should be considered to configure the system in such a way that the Primary Server is always operational when the HA pair is running.


Set Primary Server to always be the operational server (optional)

To "force" the Primary Server to always be the operational server when the HA pair is up and running, add this Event Handler to the system:

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

Redunant master.png
Primary Server set to always be the operational server


Action commands:

IF %syse(230)
STOP
ENDIF
IF %op(%syse(232),=,0)
$RESET
ENDIF


Explanation:

  • 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.


Related articles