Snapmirror NFS

[arsalankhan]

Hi,

We are trying to migrate one volume (NFS) from 8.2.5P1 (7mode) to CDOT 9.3P2 with snapmirror.

We created a snapmirror, once its mirrored we did an upgrade and then quiece/brake and mounted the destination volume (from cdot). But when we try to launch an application from the newly migrated volume its behaves differently. What I mean behave differently means, its rhel 6 GUI based app. But the font style and application appearance changes completely and it keeps on asking for Database password to connect to database.

Whereas, just to check, we also snapmirrored same source volume from 8.2.5P1 (7mode) to another controller 8.2.5P1 and update+quiesce+break it. And this new 7mode destination volume launches the same application like it source volume does, without even asking for Database password.

What could be wrong in both snapmirrors here ?

[GidonMarcus]

I suggest to check the user mapping on the cdot vs 7 mode. It could very well be that the cdot squashes out the user, while on 7 mode you maybe had it mapped to a different user or root.

the fastest way to check it is to create new file on each of them and see who’s the owner of this new file. That’s can perhaps explain why on 7 mode there’s a difference.

another thing I would do. Is to run sectrace on the cdot to see if there’s any access denied registered. 

The last thing I would do is take a packet trace from the client when trying to open the software from both platforms and try to compare the behaviour. It’s probably not going to be easy to analyse by someone not experienced in this - But the answer will sure be there 99% of times...

[TMAC_CTG]

Please review the other posts, but think about this as well...

Did the IP change for the NFS mount? Is it possible there is something baked into the App referring to the old NFS IP mount?

[Ontapforrum]

As others suggested:

First :

Raise a ticket with NetApp, if this is affecting user experience.

Second :
As you said, the SnapMirror to other ONTAP had no issues, It could be just a case where 'destination' volume was still mapping the logical blocks to physical blocks as part of deswizzle process. It depends on the load on the Node (Aggregate) where the dest_volume was hosted.

You might have just ran an update, broken mirror and mounted R/W.

Steps to isolate this:

cDOT
::> set d
::*> system node run -node <node_name> -command "wafl scan status"

node_name = where the aggregate is hosting the destination volume (NFS).

Output = If there is none for that volume, then :

1) Unmount filer vol from redhat
2) Re-mount it on redhat
3) Try acccessing again.

Third:

If it still behaves that way , use 7mtt.

Give it a try.

Thanks,
-Ashwin

[raj_shrivastava11]

Hi, Instead of using manul Snapmirror and so on, recommanded way is to use 7MTT to migrate data from 7-Mode to C-DOT.

We have done tons of migration via 7MTT in last 2 years and didnt faced any issue. It does use same Snapmirror engine but it migrate data more in controlled fashion.

BR

Raj

[paul_stejskal]

I agree with the 7MTT sentiment above.

We really need more details however on this application and your system. Do you have a case # open we can take a look?

[arsalankhan]

Case No. 2008031443