Change 3cx servers with no downtime?

Status
Not open for further replies.

RBS

Free User
Basic Certified
Joined
May 8, 2018
Messages
57
Reaction score
3
Is it possible to have 2 installations of 3cx with the same license on 2 servers, at least for one day, for smooth transition to an upgraded server at different Google Compute zone?

Best answer would be a tested and recommended practice (instead of 'yes' or 'no').
 
Not for what you want it for no. The only licence that can do anywhere close to what you want is the Enterprise licence. This is a licence which can register twice to 3CX's licencing servers (but for failover purposes - not really active > active).
 
Hello @RBS

Please note that having 2 servers activate with the same licence and FQDN is not recommended as not only you risk your licence getting locked but the DNS resolution will bounce between public IPs.
I would recommend installing the server and immediately take the other server down for minimum downtime.
 
OK, thank you. A follow up question:

Which needs to happen first?
  • GCC reserved instance for 1-3 years commitment
  • 3CX installation
 
I would favour setting it up as PAYG first and look at committed use a few days / weeks later once I had satisfied myself that the server was correctly spec'd. It would be a shame to find you had over-specified and were tied in to over-paying for 12 or even 36 months.

There are also alternative migration strategies. You can migrate GCC instances between zones within a region quite quickly / easily using the tools supplied by Google. If you need to migrate between regions (rather than just zones) it's a little trickier but you can create an image of your instance from a disk snapshot, deploy that image to the new region, shut down the old instance and then start the new. If your migration involves a change of time zones remember to update them on GCC. I would add that I've never tried this with a 3CX install myself (although I have with other instances) but I can't see why it wouldn't work. Bear in mind that, depending on the where the move is to / from, Google may force you to have a new static IP address.

In terms of downtime, your main obstacle is how long DNS propagation takes after the switch. Also, beware of any issues created by changing the IP address of your server. For example, your SIP trunk provider may be expecting traffic from a particular IP.
 
@RBS

You can't install 3CX on an instance that doesn't exist yet. GCC LTC's can't be added to an existing instance. You must create a LTC existence first.
 
OK, create LTC first, got it. We've been testing (in production) for 10 months now, and decided to stay with 3CX for its ease of configuration and next-to-none issues, once you educate yourself on the platform (I went from zero-knowledge to almost advanced over these months). Therefore, we're ready for long-term instance.

As far as different region migration, re-deploying disk image doesn't work because of different subnet used by GCC in that zone/region.
I wonder if backup can still be restored properly with provisioned extensions, at least.

And another question: if business is in FL, sip trunk is in Chicago. Would it be better to have 3CX in Chicago zone, or South Carolina (closer to FL) for less lag? (i.e. closer to sip-trunk location, or to the IP-phones?)
 
And another question: if business is in FL, sip trunk is in Chicago. Would it be better to have 3CX in Chicago zone, or South Carolina (closer to FL) for less lag? (i.e. closer to sip-trunk location, or to the IP-phones?)

That's more of a testing thing. I would usually say keep the instance closer to the point where you have the least amount of overall latency.
 
keep the instance closer to the point where you have the least amount of overall latency

How would you ping for latency a server that doesn't exist yet?
 
I wonder if backup can still be restored properly with provisioned extensions, at least.

Depends on how you provisioned them. If you used STUN and FQDN then yes. If you have an SBC then as long as the SBC is reconfigured / reinstalled correctly, yes. If you used STUN and IP address then no... they will need to be re-provisioned. If you did use IP address it might be an idea to re-provision them to FQDN before you migrate.
 
How would you ping for latency a server that doesn't exist yet?

If everything is in the same region (i.e. North America) I wouldn't worry. Latency is unlikely to be an issue.

However, if you really want to then create a free 'micro' instance in the zone you want to test, ping it and then kill the instance.
 
Last edited:
If everything is in the same region (i.e. North America) I wouldn't worry. Latency is unlikely to be an issue.

However, if you really want to then create a free 'micro' instance in the zone you want to test, ping it and then kill the instance.

This begs a new question: if calls are recorded, but "replace and re-invite" are enabled, with "pbx delivers audio" turned OFF; are connections being made directly to sip-provider > ip-phone, once call is established, or it still passes through 3cx? In which case it would make sense to install 3cx basically (possibly) in the same building as the SIP provider in Chicago, regardless of ping to local phones.
 
This begs a new question: if calls are recorded, but "replace and re-invite" are enabled, with "pbx delivers audio" turned OFF; are connections being made directly to sip-provider > ip-phone, once call is established, or it still passes through 3cx? In which case it would make sense to install 3cx basically (possibly) in the same building as the SIP provider in Chicago, regardless of ping to local phones.

If calls are recorded then all audio passes through the PBX.
 
As far as different region migration, re-deploying disk image doesn't work because of different subnet used by GCC in that zone/region.

3CX supports changing the LAN interface of an existing installation now so that shouldn't be an issue.
 
  • Like
Reactions: Lee Cramman
This begs a new question: if calls are recorded, but "replace and re-invite" are enabled, with "pbx delivers audio" turned OFF; are connections being made directly to sip-provider > ip-phone, once call is established, or it still passes through 3cx? In which case it would make sense to install 3cx basically (possibly) in the same building as the SIP provider in Chicago, regardless of ping to local phones.
If call recording is enabled then audio will pass through the PBX. Also with calls from providers to remote extension even if call recording and PBX Delivers audio is disabled audio will still pass through the PBX. It should do so to avoid any routing or one way audio issues.
 
Status
Not open for further replies.

Forum statistics

Threads
111,910
Messages
589,693
Members
164,776
Latest member
djbx83