chuck hollis in a tweet asked:
@kostadis_netapp how is this different/better than, say storage vMotion, or external file virtualization, or other alternatives? Not clear.
And that was a legitimate question, and I was going to reply in a tweet, but 140 characters is not a great way to explain anything.
In many ways, storage vmotion and file virtualization and NetApp Data Motion, are all trying to solve the same fundamental problem of separating physical storage from a logical storage container.
When evaluating technologies the question is: what are the tradeoffs?
Storage Vmotion
Storage Vmotion, vmware's product, is great if you're only using vmware and you want to move your data one virtual machine at a time. The limitations of storage vmotion are
- It doesn't work for hyperv, and it doesn't work for physical environments.
- It moves the data by schlepping the data through the physical server. NetApp Data Motion moves the storage without bringing the data back into the server
- It can't move your snapshots. If you're a NetApp customer using NetApp snapshots, storage vmotion will not move the vmdk's locked in the snapshots.
- Losing your data protection relationships. If you move a vm from one data store to another data store, any storage based data protection relationships get lost.
- Any dedup'ed storage get's undeduped as it gets transferred. This means you have to move more data for longer. You also have to pay the penalty of re-deduping after the fact.
File Virtualization aka Snake Oil
File Virtualization is, in my not so humble opinion, snake oil. The premise of file virtualization is that you can track millions of files in a meta-database outside of the file system and move individual files. But let's assume it can be made to work, a lofty and unproven claim thus far.
What are the limitations of this technology- Scale. Moving millions of files one at time and tracking the information.
- It can't move files in snapshots
- Data protection. If a file gets moved between different storage tiers, then the data protection relationship gets gummed up.
- Any dedup'ed storage get's undeduped as it gets transferred. This means you have to move more data for longer. You also have to pay the penalty of re-deduping after the fact.
NetApp Data Motion
NetApp Data Motion is, of course, perfect in every way (not!). NetApp Data Motion is great if you want to move a whole bunch of data and all of the storage based snapshots and preserve any mirroring relationships. However, there are limitations
- Requires either NetApp storage or a NetApp virtualization appliance
- The granularity of movement is large (a volume). So if you want to move a single file or vm it's not quite the right technology
- Dedup'ed data stays deduped. This means faster data transfer and no dedup after the fact.
So why was I so excited?
The reason I was so excited was because NetApp Data Motion is the culmination of a journey to build a management infrastructure that divorced logical from physical storage. Not because this is the only way to skin the storage data motion cat, even though I think the advantages of this approach are significant.
Late breaking updates...
jpwarren reminded me about dedup. Do'h!