Should I use Modeling Gateway (MG) to change versions or upgrade to a Major Release of Spectrum?
It is not recommended or supported to use Modeling Gateway (MG)to import / upgrade into differing versions of Spectrum especially major releases
We do not recommend using MG across different versions of Spectrum (especially major releases) because of:
Note:
Hello,
I am on Leave from 30thSep 2016 to 7th Oct 2016. I have limited access to Phone and mail. Any Urgent matters please call ENTIIS office @ +65 6283.7378 . Else I will respond to your mail when I get chance to respond.
Thanks
Rajesh
+65 92380924
Dave,
I know that this is digging up an old thread but there were some rather large schema changes that were made between 9.2 and 9.3+ in the database and the way that events were handled - largely due to things like UTF-8 character sets. The net result is that you need to go through the transition step from 9.2 to a later 9.x release before being able to go up to 10.x. I should add that if you have an environment with a very large number of events then it could take some time for the conversion to happen - though there are ways of speeding this sort of thing up (performing this task offline, etc.).
Have a look here for the upgrade path information to Spectrum 10.1:
https://docops.ca.com/ca-spectrum/10-1-and-10-1-1/en/installing-and-upgrading/upgrading-ca-spectrum
Ed
I have some physical Windows 2003 Standard and Enterprise servers running 9.2 HF12 & 13. We need to get them onto virtual 2012 R2 with Spectrum 10. We also have around 4-5 RHEL 5.8 servers running 9.2 HF12 that need to go to Windows 2012 R2 as well. Some of these we're reprovisioning from scratch due to the complexity of the set-up but for the lion's share we were hoping to just do a model transfer from 9.2 to 10 then tidy up.
Does this mean "officially" I have to stand up intermediate Windows 2008 R2 servers and go through a 9.2->9.3->10 upgrade and then transfer that DB to the new production SpectroServer on 2012 R2? That's an awful lot of work for what in some cases are landscapes that may be quicker to remodel from scratch. If we could install 9.2 on Windows 2012 R2 with no issues then I'd do a straight db import then go through the correct upgrade path but by removing OS support in the installers for Windows 2003 R2 etc., it creates a whole pile of extra hassle.
What I have done on one as a test, is amend the gateway export config on the 9.2 HF12 source to only do models and a few other bits (a default 9.2 export into 10 hung in a couple of places) then after a "rediscover SNMP MIBs" and "Reconfigure Models" on every device, I manually drew links back in where needed. Next I ran NewMM.pl but had to amend it slightly as between 9.2 and 10.0 some Cisco 870s and 880's had changed model type twice so the v10 NewMM.pl didn't pick up that they needed changing (looking for the 9.4 type not 9.2) even though OneClick was complaining about incorrect model type. I copied the NewMM.pl to another name, amended it to move the offending OIDs into their own bit of conversion criteria with the correct source and destination model types and ran that instead, and my models are now all functioning correctly.
If, however, you are using VC AIM, LPAR AIM etc. delete and rediscover those in Spectrum 10 as the support has improved ten-fold for most of those. It's a bit more work but still in many cases faster than standing up a transition server, going the full upgrade path, then transferring the DB to the end server.
So it CAN be done, there just needs to be a bit of extra config work on the export/import and modelling & mapping afterwards.
Thanks again for your help, Jay. I really appreciate it!
Looks like my reply was chopped apart. Here was my actual reply:
Yes, that is correct.
The modeling gateway does not capture configuration files though, it only exports models out of the SpectroSERVER database. So you will want to do a check on your <SPECROOT>/custom and see if you have configurations in there that you want on the 10.1 boxes. Assuming you do you will need to copy the files over and then you can stop/restart the SS and/or tomcat to get the files loaded (or you can use the “reload” buttons if you wish (on the VNM and in the OC Administration page). Don’t forget if you’ve customized your <SPECROOT>/Notifier/SetScript you may want to move that over too…
Cheers
Jay
The modeling gateway does not capture configuration files though, it only exports models out of the SpectroSERVER database. So you will want to do a check on your /Notifier/SetScript you may want to move that over too…
Hi Jay,
Yes, this helps. I think from what you said we could do this:
1) We run 9.3 as described in production today.
2) We've already built new VMs and have a fresh 10.1 installed (one SS MLS and two UIs). Our goal is to migrate to these new VMS and release the old Windows systems when we are done.
3) We will copy the 9.3 SSdb to the new 10.1 SS and load the models only via command line from the SS directory using the “../SS-Tools/SSdbload –m dbsavefile” command).
4) Then we will export data from the other three 9.3 SS and import to the same 10.1 SS using the modeling gateway.
Does that seem right?
Will that give us also all of our Global Collections, SANM definitions, Custom eventmap, etc?
I really appreciate you giving us the roadmap here. We haven't found this process described fully anywhere in the doc.
Regards,
Rick
Hi Rick,
It depends…If you don’t mind losing your 9.3 catalog, you could do a models only load from the 9.3 database (just take the 9.3 SSdb file, put it on the 10.1 box and load the models only via command line from the SS directory using the “../SS-Tools/SSdbload –m dbsavefile” command).
That will wipe out any/all modeling you have already done on the 10.1 box though and it will not load your 9.3 catalog…
If you need to keep your 9.3 catalog, then unfortunately the only supported method to make sure your SSdb will not have corruption would be to reinstall on the top of the SSdb file (some customers have opted to leave what’s running and stand up another vm. On the “newer” vm run the migration to update the SSdb, then take the SSdb from the new box and load it in on the original 10.1. Then uninstall Spectrum from the new vm).
Hope that helps
Thanks for that. If we already have installed 10.1 as a new install, is there a way to "migrate" in the 9.3 MLS DB as you suggest rather than wipe and re-run the install again from scratch?
Generally speaking this requirement holds true due to changes that we make in the modeling gateway code/scripts between versions. However, due to the nature of 64 bit Spectrum and the fact that we are requiring users to use the modeling gateway in 10.0 to “merge” databases, we did extensive testing and will support running the 9.2/9.3/9.4 modeling gateway export file to be used with the 10.0/10.1 import.
For your specific scenario, I would stand up the new linux box, and take one of the databases from the 9.3 (preferably the MLS) and “migrate” your database (ie. create the SS dir, unzip/rename your SSdb file and put the file in the SS directory then run the 10.1 install on top). Use modeling gateway to export the other 9.3 databases and import those in the 10.1 SS.
Hi Delcan Dempsey,
We have a 9.3 distributed spectrum environment ( 4 spectroservers, 2 UI servers and a CABI) running on Windows 2008. We want to go to a single Spectroserver, two UIs and one CABI all on Linux.
What is your recommended method/plan for this move?