11-24-2020 04:54 PM
Hi Guys/Gals,
Hope you are all doing well during these times.
I'm looking to migrate a High Scale vSZ from one datacenter to another.
Current vSZ is setup on public IP (behind a NAT). It manages WAPs and switches. Version 5.1.1.0.598.
We are looking to do the same thing in the second datacenter with a new public IP.
I have been able to set up the vSZ. At this point I'm looking for an advice or best practice on how to make this transition smooth. Here is my option that I can think of:
1.
- Load a backup of the current vSZ to the new one.
- Move all of the equipment (change the SCG IP address) using AP scripts and switch batch cli facility.
2.
- Change the SCG IP to a FQDN for WAPs and switches (not sure if it is possible).
- Load a backup of the current vSZ to the new one
- Change the IP in the DNS
3.
- Setup a new vSZ and add it to the cluster
- Let all the equipment get the new SCG IP
- Shutdown the current vSZ
- Remove the old (current) smartzone from the cluster
Please let me know which one of the above would be the preferred method. Also, if you know of a better way to do it - please let me know.
Happy thanksgiving!
Cheers,
Alex
Solved! Go to Solution.
11-24-2020 05:03 PM
Hi Alex,
Good day to you too.
If existing vSZ and new vSZ are using different IP and new vSZ can be reach from the APs then I can say option #1 is the best option.
My suggestion is to transfer APs per zones or batches so it can easily monitor if all was transfered successfully and with this option you will still have rollback plan to use the existing vSZ just in case something unexpected will happen (most case none)
regards,
Lloyd Chua
11-25-2020 12:22 PM
Hi All,
I don't want to contradict with pervious suggestions as all are correct. However, I think 3rd option is the best one.
"
3.
- Setup a new vSZ and add it to the cluster
- Let all the equipment get the new SCG IP
- Shutdown the current vSZ
- Remove the old (current) smartzone from the cluster
"
Below are the advantages with 3rd plan:
11-25-2020 12:26 PM
In addition, I suggest shutting down the vSZ on DC1 (or just shut the virtual port from VM side, so that it can easily be switch On, in case of any failure with new cluster node), make sure everything is working on new node in DC2, then only remove the old node from the cluster or decommission it from VM.
11-30-2020 11:16 AM
Thanks Syamantak_omer,
It was mentioned in the above comment that clustering between two different datacenters is not recommended. Do you see an issue in that?
Cheers,
Alex
12-02-2020 06:38 AM
Hi Alex,
It depends upon the latency between the DCs.
eizens_putnins explained it correctly in his comment but vSZ is supported on different DCs on a single cluster.
11-27-2020 04:02 AM
For clarity I want to add, that sz controller list on AP doesn't use FQDN, list contains node IP addresses (both internal and external for each node). So for AP onnects to SZ using IP address, not FQDN. It avoids disruptions because of DNS issues, but doesn't allow to change cluster target using DNS.
If you have new cluster configured and ready to go, than to move APs from one vSZ cluster to different one is really easy, you just use move menu from vSZ, and move APs to different cluster (there you can use IP or cluster FQDN). Problem is that you need during this transfer licenses available for each AP on both systems, so if you are just moving installation, it is more practical to move VMs, not to make a new installation.