But there is another technology about which I am super-excited: and that is NetApp's in-place transition. Read: No.Data.Migration. Yeah, baby!
What Is A Copy-Free Transition?
For virtualized systems, mostly, this transition is relatively painless. Just storage vMotion everything over. But even in 2015, not everything is virtualized **sad face**. And for physical servers, migrating storage data is terribly painful, and often difficult to fit into a particular maintenance window.
And this transition increases in time based on a variety of factors, not the least of which is the number of objects in the underlying storage volume. A network (CIFS or SMB) share, for example, can contain anywhere from hundreds of files to multi-millions and even billions, if properly engineered on something like NetApp's Infinite Volume.
And last, but certainly not least, there is the problem of copy-drop. What is copy-drop? It's when you are manually copying something, the copy on the current file fails, and the rest of the job is aborted without any regard for copy process. And then you have to start the copy all over again.
Fortunately, NetApp has the 7-Mode Transition Tool to mitigate some of the pains of this process. This tool will migrate both NAS and SAN volumes with their existing data. Now, there are some limitations due to the load being placed on the storage subsystem during this migration process; these are the ones I run into most frequently:
- 10 maximum simultaneous copies to ESXi hosts
- 160 LUNs/Volumes per migration project (practical limit; hard limit is 240)
A transition peer relationship is an authorization mechanism that enables SnapMirror to establish relationships between a 7-Mode storage system and an SVM in the cluster for copying data from the 7-Mode volumes to the clustered Data ONTAP volumes for transition. Transition data protection (TDP) relationships are volume SnapMirror relationships, and are supported only for transition. You should not keep this relationship for long periods of time because it is not possible to resynchronize data from a clustered Data ONTAP volume back to a 7-Mode volume.
--7-Mode Transition Tool 2.2
There has to be a better way.
What's the best scenario for a data-migration? To paraphrase Mr. Miyagi, "Best migration no migration." That's the essence of Copy-Free Transition thinking. The best, the most worry-free, the most reliable data migrations are the ones that don't actually occur because there is no need to actually perform them. The data remains in place. And this has a lot of benefits for NetApp users.
- Significantly reduced migration costs—use the hardware you have
- Transition in as little as 30 minutes
- The time to transition is not dependent upon the size of the aggregate
- Only one single maintenance window for the entire environment—physical or virtual
How can Copy-Free Transition do all this?
The metadata of the 7-Mode aggregates and volumes is converted to the clustered Data ONTAP format by the 7-Mode Transition Tool . . . converting a 10GB aggregate to Clustered Data ONTAP format is the same as the time required for converting a 100TB aggregate. — 7MTT 2.2
Storage cutover time can be 4-8 hours or less. The cutover time includes the time taken by the tool to perform two automated operations—the export and halt operation and the import operation— as well as the time taken for manually cabling the disk shelves to the new controllers. The export and import operations take about 2 hours or less. Cabling can take 2-6 hours or less. — 7MTT 2.2
So what's the process?
The implementation process for CFT itself is quite simple:
- Create placeholder SVMs (one required per vFiler, if in use)
- Disconnect clients (begin maintenance window)
- Hot-add 7-mode disk shelves to new Clustered DataONTAP controller pair
- Test the new dataset to make sure it's intact (best practice)
- Commit the changes (end maintenance window)
Very exciting! Oh, and one more thing: yes you can rollback to 7-mode if there's a problem. Nice. The 7-Mode Transition Tool takes aggregate-level snapshots of all the transitioning aggregates prior to any metadata change. Boom.