Active IQ Unified Manager Discussions
Active IQ Unified Manager Discussions
Hello,
We are currently on DFM 4.0.2.8103 (4.0.2D12) and are planning to upgrade to the On Command 5.1 suite soon. We will likely install version 5.1 on a new server, and I would like to install it in a different location than our current 4.0.2 is installed in. I ran across this in the Installation and Setup Guide on page 79:
--------------------------------------------
If you are upgrading to the OnCommand Core Package while also migrating to a new system,
you should use the original DataFabric Manager server installation path to avoid errors caused
by changes to the path setting option for DataFabric Manager server databases.
--------------------------------------------
If I use the dfm datastore setup command to move our existing DFM installation to the desired path before we upgrade, will that alleviate the issue raised above? Does the dfm datastore setup command move everything in a DFM installation (assuming you don't specify that you only want to move a particular object)? Any help will be greatly appreciated!
Solved! See The Solution
HI Thomas,
Is my understanding of your move correct as I updated in my earlier post ? If YES then the ISG test is not accurate and not applicable here.
For example I had been doing this personally for another activity.
A dfm backup from 4.0.2D12 running on linux restored it on a 5.1 DFM running on W2K8 by just copying the .ndb file and executing the cli dfm backup restore.
Just think, is it possible to move the linux path to windows as per the text in the ISG ? I don't understand why it was written and in what context.
But for sure I know its not applicable for your situation if my understanding was correct as per my summary earlier.
This situation is applicable only when you restore the monitordb.db file and not the .ndb file. In such situation the sql will not start if you dont set the dbdirlog to same as what it was in the monitordb.db. But this is something internal and not supported or recommended for customers.
Regards
adai
Hi Thomas,
Let me see if got your situation correctly. You are currently running version 4.0.2D12 on server A. You would like to Install version 5.1 on server B and restore the db backup from server A on B. Is my understand correct ?
If the above is correct, all you have to do is the following.
When you restore the db location of the server is taken care and the one on the backup file is ignored.
The install and setup guide is incorrect, let me open a bug and get it corrected.
BTW the dfm datastore setup will move things like, database, perf dir and script-plugin dir etc.
Regards
adai
Thank you Adaikkappan! So, just to be certain I am following this, are you indicating that the following quote from the Installation Guide is invalid? I just want to be sure this is correct before I move forward with developing a migration plan. I had spoken with Phil Bachman from NetApp a few weeks ago and he seemed to think that this quote was accurate, but he may have been mistaken. If the quote is accurate, I would need to do something like the dfm datastore setup command I described earlier. Thanks for the help!
--------------------------------------------
If you are upgrading to the OnCommand Core Package while also migrating to a new system,
you should use the original DataFabric Manager server installation path to avoid errors caused
by changes to the path setting option for DataFabric Manager server databases.
--------------------------------------------
HI Thomas,
Is my understanding of your move correct as I updated in my earlier post ? If YES then the ISG test is not accurate and not applicable here.
For example I had been doing this personally for another activity.
A dfm backup from 4.0.2D12 running on linux restored it on a 5.1 DFM running on W2K8 by just copying the .ndb file and executing the cli dfm backup restore.
Just think, is it possible to move the linux path to windows as per the text in the ISG ? I don't understand why it was written and in what context.
But for sure I know its not applicable for your situation if my understanding was correct as per my summary earlier.
This situation is applicable only when you restore the monitordb.db file and not the .ndb file. In such situation the sql will not start if you dont set the dbdirlog to same as what it was in the monitordb.db. But this is something internal and not supported or recommended for customers.
Regards
adai
Adai,
Thank you very much as this is a big help! In my case I am moving from a Windows 2003 server to Windows 2008, but the principle is the same based on what you are saying. Thanks again! You have just made this project a whole lot easier!
I would like to mark this as answered but don't see an interface button for it. Where/how can I mark this post as answered?
BTW Thomas,
I suggest you wait for a week or so and upgrade to 5.2 which would be GA instead of 5.1.
Also there are quite a few improvements in 5.2 Compared to 5.1
Regards
adai
Thanks Adai! I will have to recheck the Interoperability Matrix to ensure that this version is compatible with everything else, but if it is I will definitely try version 5.2!
BTW starting today UM 5.2 is GA.....
Regards
adai
Thanks Adai! I will check it out.
Adai,
I noticed on the Interoperability Matrix that SnapDrive still doesn't show compatibility with OnCommand Suite 5.2 - does it just need to be updated or is this accurate?
Which version of Snapdrive and for which purpose? Snapshot backups or DR functionality?
Kevin
We are currently on 6.4.2. We use SnapDrive on several servers to host LUNs, and we schedule snapshot backups through SMSQL or SnapDrive scripts, including DR replication.
The versions of SnapDrive listed in the IMT from the Unified Manager perspective are either for UM based snapshot backups (as opposed to archive) or DR style mirroring of the database location.
I recommend that you will want to review the SnapDrive IMT components for integration compatibility with versions of UM.
Thank kryan. I was not sure if the lack of compatibility with SD 6.4.2 mattered in our environment. What I believe I'm hearing you say is that SnapDrive compatibility only matters if we are using UM to perform snapshot backups/DR mirroring vs. using SnapDrive itself or SMSQL. Is that accurate?
I was referring to note 5521 under UM Core IMT fields discussing the versions of SDW/SDU that can be used for snapshot style UM backups (its own database/perf data) and the DR feature that can be used to mirror the UM data.
I expect that the SnapDrive IMT records will state UM Core compatibility and after checking I observed that SDU lists UM 5.2 compatibility whereas SDW only shows UM 5.1.
I am investigating the status of the SDW IMT records.
Compatibility does indeed matter - if you do not see a particular combination of versions listed within IMT you can assume it was not tested to work.
Thanks kryan, that's why we were planning to just install 5.1 for now, and upgrade to 5.2 when SnapDrive compatibility is added.
I would like to mark your post as the 'answer' but don't see the buttons. I notice they do appear on this other post of mine: https://communities.netapp.com/thread/30470. I notice that post shows 'thread' in the URL while this one says 'message' ... is that the difference?