2010-03-07 11:07 PM
Just read in announcement. Could someone give more pointers about it?
NFS transparent migration would be killer selling point for some projects. Thank you!
Solved! SEE THE SOLUTION
2010-03-08 10:20 AM
Provisioning Manager is the interface for using the Data ONTAP 7.3.3 feature of Data Motion using Vfiler for Non-disruptive Migration.
You will need Data Ontap 7.3.3 minimum and Aynsc and Sync SnapMirror license on the filers for supporting DataMotion.
2010-03-08 12:29 PM
We have used vfiler migrate which is the technology this is built upon to manually move NFS workloads transparently. As long as the applications can live through the cutover (usually 30-ish seconds) it is fine--we have had good success with VMware and Oracle though some challenges with Oracle in a data guard configuration.
There is a good TR-3814 that goes over the use cases and compatibility. There are a few errors about supported models, but an email to our local rep got an immediate response back that our models (3140's) were covered and that the documentation was incorrect and will be changed.
The biggest issue is the lack of support for migration of vfilers with de-duplicated volumes. I was told that the developers were very aware that was a desired feature. You can use vfiler migrate with de-duplicated volumes, but the TR authors said that there is a slight difference in that the new technology uses a semi-synchronous method for transferring the data which is why they recommend against it.
There are limits to the number of volumes that can be attached to a vfiler--my experience with vfiler migrate is that the more volumes the longer the cutover.
All that said--this technology is wonderful for transparent data migration.
2010-03-08 12:39 PM
Check the latest version of TR-3814 for updates around Data Motion on systems that have deduplicated data. The original version of this TR that came out stated a lack of support, but a new version was quickly released that states support for Data Motion with deduplication as long as the systems involved are not under high load.
2011-02-16 07:11 PM
I just wrote up our experiences using non-disruptive vFiler migrate to upgrade our 3040's 25Tb (in 15 vFilers) to a new 3170 with zero downtime:
I agree, this is a killer feature and I am pleased with the robust implementation - seems like magic at first, but it just works (like vmware vMotion )
2011-02-17 08:30 PM
It is indeed a nice article and gives us a good feedback on the product datamotion. It's good know that the customer could do successful datamotion using our technology.
Howevere, we do find few issues the article faced by customer during the course of moving the data. Following is one of them :
"but there were a couple problematic vFilers erroring out for unspecified reasons, which were remaining preventing us from getting off the old 3040 hardware. For these we found running the same vFiler migrate from the command line actually proceeded without error."
We would like to know
a) What kind of errors were those and did they capture those error strings/messages, logs for the same?
b) Did they face those errors during the actual cutover time or in the dry-run results?
c) How did they get rid off those errors; could they run into successful cutover after facing those errors?
It's important for us to know those errors and related queries so that we can avoid such issues in field.
I have one more query; although I think I understood the problem but still want to make sure. This is on the following:
"However, we were less than excited that the existing vFiler migration had no way to import our existing multi-terabyte snapmirror relationships. To utilize PM's vFiler migration, we had to delete these snapmirror relationships with the DR vfiler, and recreate them (sometimes taking 18 hours) re-initializing from scratch."
a) Did you mean to say that they tried to use DR vfiler initially to accomplish the migration task and resulted into some issues? If yes, what kind of issues they faced there?
b) And while using datamotion ( Provisioning Manager) did customer want to use the existing snapmirror-relationships ( out of DR vfiler) for baselining the volumes?
Your answer to all the above queries will help us building a more robust solution.
2011-02-19 12:07 AM
Hi, I¹ll review my notes and logs to see what the error was from PM, but not
from the command line
1. Did you mean to say that they tried to use DR vfiler initially to
accomplish the migration task and resulted into some issues? If yes, what
kind of issues they faced there?
Yes, we encountered an unclean arp cache clear resulting in a duplicate IP
after executing a vfiler dr activate command we had a case open on this
2. And while using datamotion ( Provisioning Manager) did customer want
to use the existing snapmirror-relationships ( out of DR vfiler) for
baselining the volumes?
Yes, we would like to re-use those existing snapmirror relationships for
baselining the volumes
2011-02-19 08:44 AM
We noticed the arp issue with 7.3.4 but it may have been introduced earlier. The workaround we use is ifconfig 0.0.0.0 or ifconfig -alias to remove the ip from the interface (even though stopping the vfiler should be enough but isn't with this bug).
For vFiler DR, there is a workaround to use existing mirrors... create the vfiler manually with all volumes mirrored manually, then stop the vfiler and then vfiler dr resync (instead of using vfiler dr configure to initate the mirrors). ONTAP 7.3.5 just added a vfiler dr configure -u feature to allow the configure command to not re-initialize mirrors that already exist, so the workaround isn't required with that. Any vfiler dr command still updates snapmirror.conf to 0-59/3 for 3 minute updates (even with existing entries) so save a copy of snapmirror.conf.
With vfiler migrate and data motion, I don't know of any way around not re-initializing the mirrors. Hopefully we get a -u option similar to what vfiler dr just added in 7.3.5.
2011-02-20 11:41 PM
I'm cusious about your vFiler DR experiance and what you actually wanted to accomplish.
During my personal testing, all vFiler DR relationships remained intact, without the need for a re-baseline.
I tested the following scenario:
Source A --> vFiler DR --> Dest B
- Replacing Source A with new System C
- Use DataMotion for vFilers to move vFilers from A to C
Source C --> vFiler DR --> Dest B
As said, no re-baseline for vFiler DR required.
Main difference, during my testing I used only some GB of data. As you migrated several TB, I assume the vFiler DR SnapMirror update conflicted with the newly established SnapMirror for the migration, perhaps losing a common SnapShot between the source(s) and the DR destination. Perhaps disabling the SnapMirror updates during the migration would have helped to keep the relationships in tact - but that's just a guess...
Generally DataMotion keeps all existing SnapMirror relationships while migrating vFilers, and as Provisioning and Protection Manager don't know anything about vFiler DR (which is sad but another story), those relationships are treated as a simple SnapMirror.
A different thing though is moving the DR vFiler. AFAIK that's not possible with DataMotion.