Documentation Downloads Knowledge How-To Hub Forums Cases Assets Warranty
Skip to main content
alex_shalima

67 Messages

 • 

1.5K Points

Wed, Nov 25, 2020 12:54 AM

Smartzone Migration

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

Question

 • 

Updated 

2 months ago

 • Edited

52

6

0

Responses

Accepted Solution

ruckus_tac_c

Employee

 • 

2 Messages

 • 

90 Points

2 months ago

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

3

alex_shalima

67 Messages

 • 

1.5K Points

Hi Lloyd,

Thank you for your prompt response.

Great, we will follow option 1. 

Happy turkey day!

Cheers,

Alex

Like

2 months ago

0

eizens_putnins

210 Messages

 • 

3.2K Points

And by the way you can't add remote vSZ node (located in different DC) to the cluster, except if you have fast dark fiber link between them. Clustre requires law latency L2 connection without ACLs (as communication between different services happens using different internal subnets, not related with interface addresses.   

Hope this helps.

Like

2 months ago

alex_shalima

67 Messages

 • 

1.5K Points

That's great to know. Thanks eizens_putnins!

Like

2 months ago

0

mario_javier_garcia_gallego

13 Messages

 • 

190 Points

2 months ago

Best regards, Option 1 seems fine to me, although I don't know exactly what it is going to send in the scripts, I have done it that way and I have migrated the APs using the "Switch Over Cluster" option. Cheers

1

0

alex_shalima

67 Messages

 • 

1.5K Points

Thanks Mario

Like

2 months ago

0

javier_valdes_chavez

30 Messages

 • 

632 Points

2 months ago

Hi Alex, I'd like to add that, if possible test the procedure on lab first just to be sure that nothing is missing. 

You could run another vSZ with demo license with a 3rd IP address and test the script to move one AP from the demo vSZ to the vSZ of the new data center.

Best regards.

1

alex_shalima

67 Messages

 • 

1.5K Points

Thanks Javier, we did test in production with backups available. This customer had no lab to test the process.

Like

2 months ago

0

eizens_putnins

210 Messages

 • 

3.2K Points

2 months ago

Hi,

It depends mainly on how many APs you have. If just a few, you can get new installation and change each AP setting manually.

If you have a lot, in different location, it is probably not a good option.

I would do it this way:

1. Plan new location to use same internal IP addresses for vSZ nodes as existing  site. It is not mandatory, but will simplify things much.

2. Copy vSZ both node VMs to new Datacenter, and change they external IPs (NAT IPs) to what is needed. Instead you can make new installation and restore cluster backup -- which will get you the same VMs, but will  require some configuration and will take probably longer. Shutdown new vSZ   for a moment.

3. Change external IP (NAT IP) of one existing node to what it will be on new site. On that stage you lose redundancy, as this second node become unusable to serve APs,  but it is not an issue. Anyway, all APs get list including this new IP than.

4. When all AP configuration is refreshed, start new vSZ. When it is up and all services are running, shutdown old vSZ.

3. Check that you have all APs up and connected. If some AP still doesn't connect, you can bring up again for a few minutes old vSZ, to get it updated to new configuration, or change vSZ IP manually.

Hope it helps.

0

0

syamantak_omer

Official Rep

 • 

733 Messages

 • 

11.4K Points

2 months ago

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:

  • Zero downtime required.
  • No need to migrate the APs manually or point them to new vSZ IP.
  • No manual configuration required on new vSZ in DC2.
  • Full database of the existing vSZ will sync with new node, not just the configuration.

Regards,

Syamantak Omer

3

syamantak_omer

Official Rep

 • 

733 Messages

 • 

11.4K Points

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.

Regards,

Syamantak Omer

Like

2 months ago

alex_shalima

67 Messages

 • 

1.5K Points

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

(edited)

Like

2 months ago

0

syamantak_omer

Official Rep

 • 

733 Messages

 • 

11.4K Points

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.

Regards,

Syamantak Omer

Like

2 months ago

0

eizens_putnins

210 Messages

 • 

3.2K Points

2 months ago

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.

0

0

Was this helpful?