Netapp: The Inflexibility of Data ONTAP

Thanks to @ianhf for posting a related blog entry berating Netapp for their lackadaisical approach in delivering features in Data ONTAP that customers really want.  My original post is here; @ianhf’s post is here.  I urge you to read it as it takes what I was saying a whole step further and was probably the post I would have written if I my use of the English language was more eloquent and structured.

So, as part of their rebuttal, Netapp employees pointed me to two features; snapmirror migrate and Data Motion.  In the spirit of fairness, I have researched these two features using the only tools available to me – Netapp documentation – and here’s what I found.

SnapMirror Migrate

This feature is similar in nature to the concept of “failover” on large EMC arrays where a remote array takes over operation of a local LUN.  As the operation is taking place on NAS, things are slightly different.  Here’s a direct quote from the Data ONTAP System Command Reference:

“The first thing migrate will do is check the source and destination sides for readiness. Then, it will stop NFS and CIFS service to the source. This will prevent changes to the source volume’s data, which will make it appear to clients as though nothing has changed during the migration. It will run a regular SnapMirror transfer between the two volumes. At the end of the transfer, it will migrate the NFS filehandles, bring the source offline, and make the destination volume writable.”

So what does this mean?  Presumably the first thing that happens is that all I/O operations are suspended and the hosts are unable to write to their target volumes.  This introduces a whole range of concerns about data integrity and data loss if any kind of outage occurs while the copy is taking place.  It isn’t clear whether the volume effectively becomes unavailable.  Here’s the next quote:

“The migrate process will not take care of renaming or exporting the destination volume.
As a result of this process, the source volume home will be taken offline, and NFS service to this filer will be stopped during the transfer. CIFS service on the source volume will be terminated and CIFS will have to be set up on the destination.”

Clearly not a transparent, non-distruptive migration then.  I’d suggest that SnapMirror Migrate is purely an extension the ability to move data to other filers and not an “in-filer” migration function due to the impacts on file handles and I/O.  Imagine moving 16TB volumes around using this approach; no thank you.

Data Motion

There’s not much to say about this product – and this time I quote from the Data ONTAP 8.0 7-mode release notes:

“Data Motion is not supported

Data Motion was introduced in a previous release, but it is not supported in Data ONTAP 8.0 7-Mode.
The Data Motion feature integrates virtual storage, mirroring, and provisioning software technologies so that you can perform data migrations non-disruptively in both physical and virtual environments.”

Whoops!  Guys, don’t try and sell me on a technology you’ve since discontinued!  I’d be pretty miffed if I’d built my process around this tool and was then told I could no longer use it.  The release notes imply Data Motion will be back again as a feature in future releases.  It really demonstrates that the ONTAP code is struggling when features have to be removed and re-introduced over time.

I stick by my assertion that Data ONTAP is becoming unwieldy and I’m obviously not the only one of this opinion.  Netapp need to pull some serious rabbits out of the colloquial hat otherwise they seriously risk losing ground to better competition.

• Pin It
• Share
• Tweet