A different perspective on this (and I don’t disagree with anything said so far) is that HA should only be available for LTS versions. If we can arguably agree on that, work on HA shouldn’t have even started until recently.
Many of the problems with HA are endemic to Asterisk and SIP. There are just some parts of the process that naturally make HA technically hard to do. I’ve believed for a long time that true HA is unattainable because of the way SIP processes calls combined with the way Asterisk implements those controls.
We have workarounds for almost all of the things HA calls for in the Hot-Spare configuration, which works reasonably well. Getting that working reliably could be considered the first step to solving HA’s issues, but for almost everyone, it’s a reasonable approach to HA.
Very true, even in an HA setup active calls are lost when the active node dies for whatever reason. The media isn’t shared between the systems. The channels are not shared. None of that is, it’s all unique to the system running Asterisk.
Has anyone tested using virtualization to combat the HA problem? Putting FreePBX in a virtual cluster (ie, VMware HA, Xen server cluster, Hyper-V cluster, etc) would fulfill that need as well. Not sure of the best cost option for HA, but if it is critical to have HA, then putting it in a virtual environment would solve that.
In fact, I believe most other phone systems work that way, at least that was my experience with Cisco, Shoretel, Toshiba IP Edge, and Switchvox. All three of those were sold as physical hardware that essentially has a free ESXi and their virtual server ran on that dedicated host.
Here is a current “HA” setup that I have for a customer.
– Two FreePBX systems, in different geographical locations (two of their offices). Just some FYI, this requirement right here made HA a non-viable option as it didn’t support servers in two different locations.
– Node B backs up and restores Node A on a time schedule.
– Both FreePBX’s share a centralize database (also master/slave sync’d) so that updates and data can be stored and accessed by both boxes if needed.
– Kamailio SIP Proxy cluster, as they have 5 locations and over 700 users. All the users connect to the SIP Proxy. The SIP Proxy is also monitoring the state of SIP on Node A and Node B. If Node A is unresponsive, it will use Node B.
– Inbound/Outbound trunk are also connecting and routing through the SIP proxy so the same thing can happen in regards to Inbound calls, it will send the call to the right PBX that all the users are on.
Now if you’re wondering “How do the devices know which SIP Proxy to use, etc, etc.” it’s called not using IPs for everything involved with SIP and using FQDN’s with SRV and NAPTR records. Pretty much how places like Flowroute and other providers do. One single FQDN to put into the phones (proxy.domain.com) and it will determine which of the SIP proxies is responding and up and send the user’s phone requests there. Same with the PBX systems (using PJSIP for SRV support).
Because the bottom line is this, there is no true “HA” solution for SIP because of how it works. In order for you to have a true “HA” system you can not have have B2BUA’s as the only piece of it. You would need a multi-system platform for signalling, media, etc, etc, etc so that things can handle the pieces of the call and be able to share them (if possible) with it’s backup/hot spare.
While I understand the benefits of HA, you guys might want to look at a “temporary” solution.
We’ve been using several Warm Spare Setup’s for quite some time now, on some we configured nightly or weekly backups, depends on the activity of the PBX, and you can even do hourly and just backup the actual config, no CDR or call recordings to speed up the process.
What makes it even easier, with Endpoint Manager for Sangoma Phones, you can specify a failover SIP Address, there you enter the Warm Spare Address.
Last time we made a drill, it took 60 seconds till ALL phones were up in the warm spare.
As there is no ETA for the new HA module, just don’t count on it and plan for something else.
As others have said, the warm spare solution looks like a good alternative, which you can convert into HA easily once the module arrives.
I have a number of Freepbx HA installs as well, which I am thinking of moving to warm spare.
While I will certainly look at the new module once it’s out, the truth is that at least in its Freepbx 13 version, HA caused a lot more problems for me than it solved.
HA sounds great in theory, but in practise the systems were much more unstable and outage prone than regular non HA installs. I had plenty of cluster failures and fail overs because of things that would otherwise have not been problems at all. Upgrades were also more difficult and caused issues.
So in short, HA comes at a cost.
If you are using dedicated servers and no VM, hardware Raid will also get you a long way, so do redundant power supplies.
Who knows. They went from “we are gonna release it any minute” to “we have no idea when it’s gonna be released”. Not sure what that means, but I am just saying, don’t count on it.
For right now we’re in no rush to update from 13, so we’re a bit less put off by the situation. If it does become an issue then that will, of course, change.
All my systems are still on Freepbx 13.
I will skip 14 and probably sometime next year do a new install of 15 and move to warm spare.
I won’t renew the yearly maintenance on the HA module (already a year behind) until the new one is out and I can take a look at it.
If I like it I will give it a chance and pay the cumulative yearly maintenance fees. Otherwise I will just stay with warm spare. As I said in my above comment, HA made things rather worse for me. Server management is harder and there were too many occasions where I suffered a complete outage because HA misbehaved.
I hope it will be better with the new module