Migration to new server

[m.jeu]

Hi,

we're planning to migrate to a new server. This is our current setup:

• sys1 - v16.0.8.9
• sys2 - v16.0.8.9 (Fail-Over)

The new system will be set up within a different vpc:

• sys01 - 18.0.2.314
• sys02 - 18.0.2.314 (Fail-Over)

Currently, I removed the Fail-Over configuration and assigned the sys2 public ip to the new sys02.

Now I stuck with the correct backup dump selection. Do I have to check or uncheck the FQDN/License checkbox? The fqdn will stay.

We're working 24/7 so the down time needs to be reduced to a min.

Best,
mje

 

[Alphabetic]

You dont want to uncheck anything.

You will want a complete backup from A to B.

Note that the DNS for your FQDN might not update straight away to your new IP.

 

[m.jeu]

Thanks for the fast reply.

ok, understood. So the next steps will be:

• import dump
• re-setup fail-over between old sys1 and new sys02
• scheduled backup and restore
• test
• switch off sys1 -> sys02 becomes active
• set up sys01
• dump and import backup
• re-setup fail-over
• done

DNS fail-over is done by AWS with primary and secondary DNS entries for that fqdn and health status checks

Did I missed anything?

Best,
mje

 

[Alphabetic]

AFAIK both active and passive server need to be exactly the same 3CX version too.

Are you not able to upgrade your v16's and then set up failover between sys1 and sys01 then sys01 to sys02?

 

[m.jeu]

ouch ... thanks for that hint. Will think about it. Maybe I'll skip that part with the fail-over step between the two versions.

 

[Alphabetic]

You may be better off doing a backup and restore to v18 than setting up your failover. When you restore to v18 it will upgrade your license from v16 to 18 so not sure how immediate the change in license will affect your v16s.

 

[NickD_3CX]

The way I usually suggest this being done does require a scheduled down-time (duration depends on backup size...).

If I understand, you want to migrate your Active/Passive installations to other machines at the same time of upgrading to V18, right? If this is the case, what I would do is:

1. Take a new Full Backup of your Active 3CX Server.
2. Power down or uninstall the Passive server
3. On the new platform, first install your New Passive server, start the installation, restore the backup and at some point of the config wizard, it will ask you for the Public IP. DO NOT select 'auto-detect', instead enter manually the Public IP that the new Active Server will have.
4. Finish the installation of the New Passive server
5. Power off or uninstall the current Active Server
6. On the new Platform, install 3CX, restore the same backup and proceed through the installation normally, but here set the correct Public IP Address for the New Active Server.
7. Log into the Passive now, set it to failover mode
8. Once the services stop, go to Settings --> Network on the Passive 3CX and set the Public IP to what it should be (until now it should have the Public IP of the Active).

 

[m.jeu]

Hi,

Thanks for the steps. The public IP addresses will stay the same. We have two public Elastic IP addresses and the DNS is handled by AWS Route53. There you can set up two ip addresses for the same record. You define primary and secondary and with the help of health checks you can define cases when aws switches the dns resolution. Right now we're monitoring port 5002 if this is available. If not, aws will fail-over the public IPs.

So therefore I also could assign the elastic IP from the current passiv server to the new one and import the entire backup including the public ip, right? In the moment the import is done, everything should be ready so that I could switch off the current active one and AWS will point to the new passiv one. Right?

 

[NickD_3CX]

Let me re-write the steps then to make sure it is understood.

1. Take a new Full Backup of your Active 3CX Server.
2. Power down or uninstall the Passive server
3. Install your New Passive server, start the installation, restore the backup and at some point of the config wizard, it will ask you for the Public IP. DO NOT select 'auto-detect', instead enter manually the Public IP that of the Active Server currently has.
4. Finish the installation of the New Passive server
5. Power off or uninstall the current Active Server
6. Install 3CX for the Active Server this time, restore the same backup and proceed through the installation normally, but here set the correct Public IP that the Active should have
7. Log into the Passive now, set it to failover mode
8. Once the services stop, go to Settings --> Network on the Passive 3CX and set the Public IP to what it should be (until now it should have the Public IP of the Active).

 

[m.jeu]

Ok, I think I got it now (hopefully).

I still think about the point of the down-time and how long that could be.

At step 5 I could re-assign the elastic ip address of the old active server to the new one and the dns should automatically point to the new active system, so that I could setup the new passive server afterwards, correct?

 

[NickD_3CX]

I wouldn't recommend moving the Active Server first, then the Passive, because you risk the current Passive becoming active.

Regardless though, if after you finish the whole process and the IP of the FQDN is resolving to the IP of the Passive, what you would need to do then in the Active server is:

1. Go to Settings --> Network and switch to "Dynamic" and press OK
2. Restart the SystemService only
3. Wait 25 minutes
4. Go to Settings --> Network and switch back to "Static", make sure the correct IP is there and press OK

 

[m.jeu]

ok, but I could switch off the passive first and then do the mentioned way without the risk of an other system jumping in.

So the steps could be:

1. switch off passive
2. full backup active
3. setup new active
4. import backup without auto-detect and enter public ip address
5. re-assign elastic ip to new instance
6. restart services
7. setup fail-over

25min of down-time is just not possible for the call center. It is getting calls 24/7.

 

[NickD_3CX]

ok, but I could switch off the passive first and then do the mentioned way without the risk of an other system jumping in.

So the steps could be:

1. switch off passive
2. full backup active
3. setup new active
4. import backup without auto-detect and enter public ip address
5. re-assign elastic ip to new instance
6. restart services
7. setup fail-over

I suppose you could do that, yes, just remember when you setup the Passive, put the Public IP of the Active during the installation. Also note that once it completes the installation, if you have Registered-based SIP Trunks, those will registered which might disrupt incoming calls for a few minutes, so once the installation of the passive completes, be as quick as possible setting it to Passive mode and changing it's public IP. (if you have IP Based SIP Trunks you should be OK)

25min of down-time is just not possible for the call center. It is getting calls 24/7.

I understand, but I think you should warn them that there may be some minor interruptions for a short amount of time.

 

[m.jeu]

Thank you - highly appreciate your time and effort! I'll sleep a bit about the plan. I already requested a test license from our partner, so I can go through this separately once to get an idea if this will work or not.

One last question regarding the new passive - why do I have to enter the public IP from the active there? I have a spare public ip address for this and in case of the active goes down at one point, the dns fail-over will jump in and point to the passive one.

 

[NickD_3CX]

One last question regarding the new passive - why do I have to enter the public IP from the active there? I have a spare public ip address for this and in case of the active goes down at one point, the dns fail-over will jump in and point to the passive one.

Because when you install it, at first it will not be in "fail over" mode, so it will "bind" the FQDN to it's own IP, but you don't want that.
That's why you tell it that's IP is that of the Active, so even though it will "bind" the IP, it will bind it to the IP of the Active, so no harm done...

 

[m.jeu]

ah! - got the point. Nice one

Thanks again - have a nice weekend!

 

[NickD_3CX]

You too!