Home › Forums › HAast (High Availability for Asterisk) › General › All HA for PBX based on open source?
Tagged: configuration generator, postgresql
-
AuthorPosts
-
I’m researching HA products for our PBX. We run an Asterisk PBX with approx. 300 active calls at any time. We use a config generator (but only to create our config files, nothing else).
We have three admins with 25+ years Linux here, and they are saying the open source packages are not suitable for PBX HA (only file HA). I also was told by a vendor of PBX software (and their own HA module) that every HA for Asterisk on the market uses the same open source packages, so they’re all the same.
Are you just selling me the stuff as everyone else? (Open source/free file-level HA packages)
Telium wrote HAAst from top to bottom in C++, and we agree with your Linux admins that the open source packages are not well suited to application level HA. The open source packages are great if you want to create a HA print server, file server, etc. However, they have no understanding of, or visibility into, the PBX, the environment, trunks, etc. The open source packages work at the OS level, not the application level and as such don’t create an HA PBX which can survive real world failures. For example, a route becoming unavailable at the ITSP, the PBX running out of file handles, a data center router going down, etc. would all trigger a failover with HAAst, but open source packages would likely leave you with a non-functional PBX.
Aside from HAAst, every other HA solution for PBX’s is based on essentially the same open source packages. HAAst does not use open source packages for any detection, heartbeat, failover control, etc. But, you are welcome to use open sources packages with HAAst if you like. (There are some things open source does well and we don’t want to reinvent the wheel). Although the HAAst product tabs do a good job explaining the differences between HAAst and the open source / commercial products but here are a few highlights:
Heartbeat & Health: The open source heartbeat/health package does not take into account the health of Asterisk, status of trunk & route availability, available file handles, available memory, etc. latency between devices, calls successfully bridging, etc. Open source packages do dead/alive detection of the box/process (and are not Asterisk operations aware). HAAst has its own proprietary heartbeat and health detection, written exclusively to monitor and detect Asterisk PBX’s and their environments. By default HAAst detects 18 different factors which degrade node health (including talking directly to Asterisk through the AMI to assess health), and can also use an unlimited number of customizable sensors.
Synchronization: Open source packages like DRBD (or other shared disk solutions like NFS/Samba/iSCSI/Corosync/Rsync/etc.) put your data at risk since file corruption by one failing peer immediately corrupts files of the other peer. With those open source solutions a failing process on one peer may destroy your entire cluster. As well, network loss during data sharing may leave your files corrupt and SQL databases in invalid states (the database might not start with corrupt tables, and Asterisk might not start with corrupt config files). HAAst synchronizes data between peers, but only if the peers are healthy. HAAst synchronizes databases (MySQL/PostgreSQL/SQLite) at the SQL transaction level, so you are never left with corrupt tables (and a PBX that won’t start). And to top it off, HAAst can maintain snapshots of healthy critical files, stepping backwards through previous snapshots to find a system state that allows the PBX to start after failure.
Security: HAAst has an encrypted link between peers so there is no risk of Man In The Middle attack, and no risk of hackers gaining control of the PBX. Open source products have well published and unencrypted protocols that are easy to tap into, and a novice/script kiddie can bring down the cluster using this information.
Other: There are lots of other functional differences as well – have a look at the features tab of the HAAst web pages for an overview of what HAAst does, and then look at the comparison tab to see what generic tools can’t do.
Performance: The bottom line is: how do these HA solutions perform in real life. There’s a reason that emergency service gateways, hospitals, airline call centers, etc. choose HAAst. From complete detection, to avoiding false positive failovers, to speed of failover, to moving resources, etc. nothing comes close to HAAst.
All of the open source packages are wonderful products in their own right, each with a specific purpose. If you spend enough time adding your own code on top of these then you can start to add application level HA functionality – but its up to you to code it. After 10 years of continuous development we have created a very sophisticated product which can detect and recover gracefully from an enormous number of failure scenarios, building our own heartbeat/synchronization/health detection/etc tailored to telephony environments.
So unlike some other HA ‘solutions’, HAAst is not a collection of open source packages relabeled as an application level HA product. Check out the HAAst web page tabs to see why HAAst is the only solution for hospitals, police/fire/911 call centers, mission critical call centers,etc. So your Linux admins are right – open source packages are NOT suitable for application level HA (as would be the case with a PBX), and that’s why HAAst is the choice of large call centers/fire departments/emergency service gateways/etc.
I should also point out that during the past 10 years three other companies have released HA products for Asterisk. The products didn’t work well, and once their customers realized all of the conditions / use cases which their HA software could not handle (and the resulting outages) they switched to HAAst. All three of those companies are now out of business / disappeared, or their HA products have been discontinued.
You’ll see new HA products pop up on occasion, because you can add ‘HA’ type open source packages in just a matter of hours. But there are no open source packages for application level HA (that’s up to the application developer). Adding HA level code at the application level (or trying to add it to file level HA packages) is a massive undertaking (measured in person-years of development, not hours).
HAAst has been on the market since 2005 and has been growing in capabilities ever since!
Please note that as of January 1 2020 support for new Configuration Generator platforms has grown. As well, support for rarely used database platform (PostgreSQL) has be deprecated.
See the EDITIONS tab of the HAAst product for more details.
-
AuthorPosts
- You must be logged in to reply to this topic.