HAsm health sensors can detect a range of  switching engine failures (not just a stopped process), as well as failure / degradation of telephony services, the environment, external network devices, upstream proxies, ITSP/carrier routes, and more.  Telium can create custom sensors for hardware/device/service you choose, contributing to the overall health score for the node. HAsm health sensors allow a node to assess its overall ability to operate effectively, and take action when health is critical (including running programs or failing over to the other node).

HAsm incorporates extensive synchronization capabilities, including the ability to synchronize files and directories, PostgreSQL/SQLite/MySQL databases and tables, and even custom data structures between nodes. Synchronization takes place from the active to the standby only if the active node is healthy, and only at intervals specified by the administrator. HAsm can even alter the received data, allowing the standby node to overwrite settings/data after synchronization (for differences between nodes).  SQL synchronization is always performed using SQL transactions (not block level copying), so there is never a risk of corruption if a node fails mid-synchronization.

HAsm incorporates the ability to share an IP address between nodes, allowing for the cluster to failover without any changes required to upstream or downstream devices. The shared IP is added/removed by HAsm as either a physical NIC, a virtual NIC, or as a virtual VLAN NIC. HAsm also broadcasts network changes to neighboring switches / routers to ensure traffic flows to the new device immediately.  User agents with active audio / video connections continue unaffected, without any interruption in service.

HAsm nodes do not depend on any shared hardware, software, disks, databases, etc. Some high availability solutions share a block level device (eg: DRDB), a channel bank (eg: Astribank), a physical disk, a USB device, etc. However, these create a single point of failure that can collapse or corrupt an entire cluster when they fail. HAsm creates completely autonomous nodes, ensuring that one node cannot detrimentally affect the other.

The design of HAsm allows for nodes to be separated over large distances (e.g. different continents) and still operate as a single cluster. All communications, synchronization, and control has been optimized to minimize data transfer and adapt to varying latency / network conditions.

HAsm can keep calls in progress up during a cluster failover, transferring active calls from the active to the standby node.  HAsm can also synchronize call queues to ensure agent and caller information is preserved.  HAsm can even run scripts upon recovery to take action on calls that were moved between nodes, including playing a message, starting call recording, etc.  Callers won’t notice the failover, as audio and video streams (RTP) can continue uninterrupted.

HAsm incorporates a heavily optimized sensor engine and cluster controller, which can detect a failed node in under 0.5 seconds and transition to the peer immediately thereafter. An entire cluster can now failover in as little as 3 seconds, with typical servers failing over in 5-15 seconds.  During this time calls can stay up and audio/video continue uninterrupted.

HAsm can treat nodes as equals (with either node continuing in an active role indefinitely) or as primary/backup (with the backup nodes returning control to the primary node when permitted). HAsm intelligently transfers control from the backup node to the primary node once the systems are stable and the cluster is reconnected, during a specified time window, when the systems are idle, etc. as specified by the administrator. This intelligent fallback feature allows administrators to move VoIP traffic back to a primary system when users are least affected.

HAsm runs at the application layer (above Linux),  allowing for considerable differences in peers including different hardware, different Linux versions, etc. This feature also allows administrators to upgrade portions of one node without risk to the cluster, then switching the active node and beginning upgrades on the other.

Cluster nodes can be safely placed on opposite sides of insecure networks as all HAsm communications between nodes is encrypted.  HAsm uses 256-bit encryption to ensure that control of the cluster is never at risk, and performance/call data is never exposed.

One of the most powerful features of HAsm is the event handler system, which lets administrators connect to events generated by, or detected by, HAsm . For example, events related to node promotion / demotion allow administrators to automate changes to firewalls, routers, etc. in order to redirect VoIP traffic to the active node prior to the switching engine starting.  These changes can happen on the HAsm node, or result in a notification sent over the API for your application to deal with.

Administrators will be immediately comfortable with the simple and powerful telnet interface to HAsm . The entire cluster can be managed and controlled from a single telnet interface, whether from a PC, a tablet, or a cell phone. The interface includes online help and user friendly, rich terminal output.