Active IQ Unified Manager Discussions

Changing DFM Installation Path Before Upgrading

TMADOCTHOMAS
8,454 Views

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!

1 ACCEPTED SOLUTION

adaikkap
8,447 Views

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

View solution in original post

17 REPLIES 17

adaikkap
8,358 Views

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.

  1. Install OCUM 5.1, (though I would suggest you to go for 5.2 which will be GA in couple of weeks) in your preferred location in server B
  2. Take an archive backup of the DFM 4.0.2D12 on SeverA.
  3. Copy the backup taken in step 2 to <installdir>/DataFabric Manager/data directory of Server B
  4. Execute the cli dfm backup restore <backup filename>

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

TMADOCTHOMAS
8,358 Views

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.

--------------------------------------------

adaikkap
8,448 Views

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

TMADOCTHOMAS
8,358 Views

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!

TMADOCTHOMAS
8,358 Views

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?

adaikkap
8,358 Views

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

TMADOCTHOMAS
8,358 Views

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!

adaikkap
8,358 Views

BTW starting today UM 5.2 is GA.....

Regards

adai

TMADOCTHOMAS
7,541 Views

Thanks Adai!  I will check it out.

TMADOCTHOMAS
7,540 Views

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?

kryan
7,540 Views

Which version of Snapdrive and for which purpose?  Snapshot backups or DR functionality?

Kevin

TMADOCTHOMAS
7,540 Views

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.

kryan
7,540 Views

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.

TMADOCTHOMAS
7,540 Views

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?

kryan
5,782 Views

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.

TMADOCTHOMAS
5,782 Views

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.

TMADOCTHOMAS
8,358 Views

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?

Public