We are upgrading our traffic manager solution. We have new hardware and VMs and have installed a new version of Stingray Traffic Manager. We want to port over the traffic ips, virtual servers, pools, monitors etc. But we want to retain the new traffic managers System Networking IPs, hostname, DNS etc.
Is there a way to take a backup of the old traffic manager and import it to the new one without erasing the Networking section? If the new one takes on the old traffic manager's host IP can we restore the new IP to the traffic manager? Will there be a conflict between the two(becuase they have the same IP) until that time?
Solved! Go to Solution.
I was able to confirm in my lab that a 9.4 version can be added to a 7.3 version, 7.0r3 should work fine. I am not sure of the version limits, but I use this method frequently with the 7.3-9.X versions. The catch are the fixes and functionality in the new version not available in the old, also the reason the Traffic Managers will give you messages.
First things first, as always make backups and make sure you join FROM THE NEW INSTANCE UI.
Join from the NEW instance so you don't erase your existing OLD instance (I have made this mistake a few times)
Once the cluster is complete the OLD instance will give you the following message:
WARNING: Your traffic managers are running with different software versions. Please upgrade the older traffic managers as soon as possible.
Configuration updates will not be distributed across your cluster as newer versions may use different configuration settings.
Your NEW instance will display the following message
Configuration update refused: Zeus Traffic Manager version mismatch
You should break the cluster from the NEW instance before you make any changes. You can leave the OLD instance with its config powered off as a backup.
A configuration backup will contain machine-specific information from the traffic manager it was taken from, such as Traffic IP Groups. When restoring a backup you can select "Restore the backup without any machine specific information." when this is selected machine-specific configuration stored in the backup is ignored, and the current traffic manager local machine configuration retained.
Alternatively you can also use partial backup/restore operations, or utilize Traffic Manager clustering to transfer the services to the new instance.
Clustering would be a great solution, but the versions of Stingray differ quite a bit. We are currently running 7.0r3 and moving to 9.2. I assume this would provide an issue if they exist in the same cluster correct? What would be an acceptable difference in version for clustering to work and to replicate to the new instance?
I was able to confirm in my lab that a 9.4 version can be added to a 7.3 version, 7.0r3 should work fine. I am not sure of the version limits, but I use this method frequently with the 7.3-9.X versions. The catch are the fixes and functionality in the new version not available in the old, also the reason the Traffic Managers will give you messages.
First things first, as always make backups and make sure you join FROM THE NEW INSTANCE UI.
Join from the NEW instance so you don't erase your existing OLD instance (I have made this mistake a few times)
Once the cluster is complete the OLD instance will give you the following message:
WARNING: Your traffic managers are running with different software versions. Please upgrade the older traffic managers as soon as possible.
Configuration updates will not be distributed across your cluster as newer versions may use different configuration settings.
Your NEW instance will display the following message
Configuration update refused: Zeus Traffic Manager version mismatch
You should break the cluster from the NEW instance before you make any changes. You can leave the OLD instance with its config powered off as a backup.