2009-11-04 01:46 PM
We are about to upgrade from OM 3.7 to 3.8. At the same time its going on a new and more robust server. My question is simple:
- Can I run two instances at the same time? I want to install 3.8 on the new server, "restore" a backup to it and run the new version
in paralell with the older instance so that I sort of get to test the new setup. Will this work? Cant see why not myself, it would create
more traffic but thats about it?
PS: I should have asked this too: our current OM is a windows version, on new version is Linux, will upgrading even work?
Message was edited by: eric.barlier
Solved! SEE THE SOLUTION
2009-11-04 02:10 PM
Hi Eric --
Yes, that will work. You will need to be careful if you run scripts, configuration management, Protection Manager or Provisioning Manager (basically anything that will perform active management on the storage systems). Those could interfere with each other.
You are correct this will generate additional load on the storage systems, so keep an eye on that to decide whether it's acceptable.
I'm not sure how the licensing will work out. NetApp pays a royalty to our component vendors for every installed DFM instance. I don't know if we have an exception for transitions like this.
2009-11-04 02:10 PM
It definitely does work. It will create a lot more traffic to the system, particularly if you have PerfAdvisor enabled from both systems.
You might want to consider disabling perfadvisor on the new system until the upgrade is fully complete. Then when your upgrade is done, and the monitoring part of DFM is fully up and running do the following.
move the perfdata directory on your new server to a _tmp
dfm options set perfadvisorenabled=off on your old system
copy the perfdata directory from your old server to your new
rename the perfdata directory on your old server to _old
set options set perfadvisorenabled=on on your new system
That way your perf data history will be continuous (except for copy time) and you won't have any dual performance monitoring of your systems
We have used this method in the past for several types of issues.
2009-11-04 02:15 PM
I've had firsthand experience with what you're proposing (which probably doesn't surprise you).
I've found issues with ONTAP that if you monitor a Filer with more than one OM server the second OM server needs to use a different license key. It caused a system panic so it was not a trivial problem.
I'll see if I can dig out the info on the incident and determine whether its fixed in a later version of ONTAP than when I first encountered the issue.
2009-11-04 02:34 PM
Hi Richard --
I'd be interested in hearing the release number too. In development and testing, we routinely have storage systems monitored by 3, 5, 10 or more DFM stations. I haven't heard of one panicing recently due to license issues.
We generally don't run the storage systems with heavy read/write loads, which is why we get away with it but don't recommend it to customers.
2009-11-04 03:11 PM
Very interesting indeed, I wonder if the crash would have been due to separate serials? If I could run the same SN on both instances it would be seen
as one instance (?) and it would not crash..
Anywys, I ll look into if I can run with same serial and take it from there.
Thanks and good to hear from you again!
2009-11-04 03:54 PM
Found it. Bug 187970 because we had systems running 184.108.40.206 at the time.
It's an SSH bug rather than an OM bug but somehow out of the situation we also developed a best practice of having unique license keys per OM instance (not sure how but then details are sketchy as this was a while ago). Because OM uses SSH the likelihood of these kind of SSH bugs on the Filer are exaggerated when more OM instances are added to the environment.
At the time we also had concerns with the last sentence in point 2.5 on the following document:
The wording was open to interpretation especially when differentiating between monitoring and management functions. From a provisioning and protection manager perspective I think you've already mentioned its best practice to only manage via one instance.