HAfs health sensors can detect a range of FreeSWITCH® failures (not just a stopped process), as well as failure / degradation of the telephony server, the environment, external network devices, upstream proxies, ITSP/carrier routes, and more. HAfs even allows administrators to create custom sensors from any script file or executable, contributing to the overall health score for the node. HAfs 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).

HAfs incorporates extensive synchronization capabilities, including the ability to synchronize files and directories, the FreeSWITCH configuration and operations databases, and any PostgreSQL/SQLite/MySQL databases and tables 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. HAfs 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.

HAfs 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 HAfs as either a physical NIC, a virtual NIC, or as a virtual VLAN NIC. HAfs also broadcasts network changes to neighboring switches / routers to ensure traffic flows to the new device immediately.

HAfs 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. HAfs creates completely autonomous nodes, ensuring that one node cannot detrimentally affect the other.

The design of HAfs 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.  Geographically dispersed cluster features are available in the Unlimited and OEM Edition of HAfs only.

HAfs can keep calls in progress up during a cluster failover, transferring active calls from the active to the standby node.   HAfs will also synchronize call queues to ensure agent and caller information is preserved.  HAfs 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.

HAfs incorporates a new 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 FreeSWITCH servers failing over in 5-15 seconds.

HAfs can treat FreeSWITCH 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). HAfs 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.

The HAfs software resides as a layer between Linux and FreeSWITCH, allowing for considerable differences in peers including different hardware, different Linux versions, different Asterisk versions, and more. 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 HAfs communications between nodes is encrypted.  HAfs 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 HAfs is the event handler system, which lets administrators hook any program/script into events generated by or detected by HAfs. 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 FreeSWITCH starting.

End users and administrators will appreciate the ability to quickly view the status and health of the HAfs nodes from an LCD panel directly on the front of the telephony device chassis. Administrators can optionally enable control of the cluster from the panel as well, allowing end-users to promote/demote/shutdown the node with the push of a button on the front of the chassis.

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

Seasoned administrators and novices alike will be comfortable with the simple and powerful browser (web) interface to HAfs. The cluster can be managed and controlled from any browser, including a PC, a tablet, or a cell phone. The interface includes simple control over the cluster, viewing of event logs, and more.

Developers will appreciate the socket, PHP, and REST (Representational State Transfer) interfaces to HAfs, as the power and control of HAfs can be easily expanded and integrated with other system administration and monitoring tools. HAfs includes sample code to demonstrate how to extract data and control HAfs via a web service, via a PHP class, and via the socket interface.