Failover

[fgc92210]

We have been working with other vendors for 20 years which have this type of failover:
MAIN Cpu, Standby CPU
Everything is done in the main and automatically copied in the StandBy.
When Main goes down, Standby immediately takes over, without failing current communications.

I see in 3CX that the failover is not setup with a "automatic backup schedule" in the documentation at https://www.3cx.com/docs/failover/
Is this voluntarily, and does it mean that f the stand by takes over, no change should be made until the old Main becomes main again?
I'd assume with the current documentation that if the standby doesn't take backup of itself, if any changes are made, they will be lost, since 1) there is no immediate synchronization and 2)there is no backup to be taken?

Can someone confirm / explain?

Thank you

 

[fgc92210]

I am noticing this too:

An Enterprise (ENT) or Professional (PRO) license key is required in order to enable the failover functionality. With an ENT license key, the DNS TTL resolution for a 3CX provided FQDN is set to 5 minutes, whereas a Pro license key uses a 6 hour TTL causing a much longer reconnect time for IP phones, 3CX Apps, 3CX SBCs or the 3CX Web Client.

so if I understand correctly, if an installation use a Pro License, and 3CX DNS Server, they might have to wait 6Hrs before their STUN phones can register again..?

 

[cobaltit]

The failover document seems to be fairly self explanatory to me. But yes your understanding of both is correct. I don't really see an issue with the passive server not getting backed up. You really shouldn't be making changes to the backup in an active/passive setup anyways.

But there's no need to use 3CX failover. Generally if someone thinks having their PBX down for any period of time is that painful, then they already have failover setup for other aspects of their business so just use that. IE VM clustering, cloud, etc.

 

[fgc92210]

The failover document seems to be fairly self explanatory to me. But yes your understanding of both is correct. I don't really see an issue with the passive server not getting backed up. You really shouldn't be making changes to the backup in an active/passive setup anyways.

But there's no need to use 3CX failover. Generally if someone thinks having their PBX down for any period of time is that painful, then they already have failover setup for other aspects of their business so just use that. IE VM clustering, cloud, etc.

Customers are moving more and more their apps to the cloud, including PBXs.
We had an experience lately where one person said a VM would never crash, and we did not agree with it.
6 months down the road, the VM crashed and was unable to boot. Thank god we quietly take images of our customers VM weekly. So we were able to restore with not too much loss of data.

The issue is not only that a VM can crash, it's also the network reaching the VM. Regardless of all the redundancy we can setup, CTO never link having anything down. People are now use to fast internet being up all the time.
Some in high positions dont understand the technology and want nothing to go down ever, nor loss anything ever.

I'm not here to argue or prove anyone wrong, but trying to calmly deal with it and do everything I can to help customer IT teams when we are not contracted to run their network. We are pretty big with other vendors, but small with 3CX. Our customers are large and extra large, up to 130K phones. We love the product (3CX), but it gets compared all the time with what they currently have.. For healthcare and financial industry, uptime has to be five nines. We understand that if the phone system is down, it means they have other more important things to look at (network), but once again, this is not a good answer. Part of our job is to keep everything up at all time. And while the network can take a hit, we need efficient redundancy on the phone system.

So it looks like the best solution is to have the FQDN hosted on an internal DNS, and use load balancing with NGINX for example?

my.domain.com -> NGINX -> Test 3CX Main UP? Yes -> forward the traffic there. 3CX Maindown? Forward traffic to stand by

No time to make tests now, but it looks like the end answer for our proof of concept.

 

[ChrisC_3CX]

@fgc92210

While we can only recommend and comment on using the 3CX Failover, I do suggest that you consider the following points when thinking of implementing your own failover configuration:

1. The two 3CX PBX's must have identical configuration.
2. Having both 3CX PBX's fully running at any given moment will inevitably cause issues such as SIP Trunks attempting to register from both PBXs and the DNS Record for the FQDN alternating between the two IPs, provided of course that you are utilizing a 3CX FQDN and that the machines are using different Public IPs.
3. The 3CX Failover will take care of these issues as, when in Passive mode(stand-by) certain services are automatically stopped such as the SIP Server, and it will not attempt to update the 3CX's FQDN IP unless a failover event occurs.

If you're worried about the DNS TTL, please note that using Google's DNS on your remote sites may help speed up the process. Alternatively, you could of course utilize a local DNS server on your remote site so that you can manually update the FQDN at will or better yet, have a script to update the record automatically for you everytime a failover event occurs.

3CX Failover: https://www.3cx.com/docs/failover/

 

[fgc92210]

@ChrisC_3CX

I understand and agree with your points.
I was just trying to find a solution where the DNS does a fast-er update for remote locations and/or STUN setups.
Maybe use Audiocodes & NGINX RP.

The issue we had during our tests is that when the main failed, it of course took a while for STUN locations to be back up and running due to the TTL. I was just looking for a work around about this. Maybe use NGINX RP and script load balancing + SIP/WebRTC Forward. We'll check this out in our lab over the spring. Thanks for the input!