7-mode 8.2.4 FAS3220 migration to FAS8040 CDOT 8.3.2 using 7MTT CFT 2.3.1

[911Eric]

Hi everyone, as the subject states, I am currently involved in a project to migrate our 7-mode HA pair over to a new FAS8040.  We plan to reuse our existing disk shelves and swing them over to the new system which is why we've chosen the 7 mode transition tool with Copy Free Transition (version 2.3.1).  The FAS8040 has a single DS2246 on it now and so far what we have done is basically connect the 8040 into our brocade fabric and vmotion critical VM's over to the 8040 system (this was done a couple of weeks ago with a NetApp PS Engineer and we ran into some problems which prevented us from completing the disk shelf migration).  So, as it stands now we have both systems running in tandem, the new 8040 has our critical VM's running and the 3220 7-mode system is running the rest of our not as critical VM's.

NetApp is going to send out their PS Engineer once more so that we can hopefully complete this transition and I guess I'm basically just looking for input from the community to ensure a successful transition.

As of this writing, the 7MTT with CFT prechecks are completing (with some warnings but no errors).  We have created our 2 SVM's that will be used for mapping the vfilers from the 2 controllers of the 7-mode system, our ESXi hosts have been added to the initiator group of one of the SVM's which is currently running our production critical VM's and I believe I'll need to add the same ESXi hosts into the igroup of the second SVM that currently has nothing running on it (the second SVM was created as a pre-requisite of the 7MTT prechecks).

I've added the WWPN's of both SVM's into our brocade redundant fiber channel switches and our pathes from the ESXi hosts look good showing 24 paths to each of our VMFS datastores.

Has anyone attempted a similar migration and if so, what else should I be double checking?  My thoughts are now that the WWPN's for each SVM are loaded into the fabric and we have green lights on the 7MTT that we should be able to proceed with the migration allowing the 7MTT to run it's course and eventually swing the 7-mode disk shelves over to the new system and bring them back online with the CDOT 8.3.2 system and then slowly bring the volumes and datastores back online in our VMWare environment.  So far it has been difficult finding people with a lot of knowledge on this process because of how new it is, I've read over documentation as has the NetApp PS Engineer I'm working with but it still seems that there are some vague unknowns and I just want to cover as many bases as I can before we attempt once more to complete this transition, which is looking like it might be as soon as 7/16.

Thanks in advance for any input.

[parisi]

I've not done FCP migrations with CFT, but I have done iSCSI cutovers (mainly for demo purposes). Worked fine for me.

As long as the hosts can access the paths properly on the cluster, you should be fine since you're getting no pre-check failures.

You could always create a test SVM on the destination system and a lun to the host to see if it presents properly beforehand. I believe 7MTT now allows you to do transitions with CFT even if the destination has data, but I think there has to be an HA pair available, so it would make sense to blow away the test SVM once you verify it works.

Your action plan after the cutover sounds fine to me.

All the cutover does is take the 7Mode shelves and converts the aggrs to cDOT style aggrs and then populates the objects from 7-Mode it loaded during the process (luns, volumes, qtrees, exports, rules, igroups) into the cDOT replicated database. The connectivity portion of the cutover is identical to how the protocols normally work.

[911Eric]

Thanks for the response.

I was able to verify with NetApp that the 7MTT 2.3.1 does now support data on the target cluster, and as such, we have 'critical' VM's that were migrated up front to the new CDOT system so that those particular VM's do not experience any downtime during the cutover, and the prechecks are completing with that live data.  So as it stands now, the CDOT system has 2 SVM's on it, both of which have been added to our FC zoning and one of which is hosting the aforementioned critical VM's, so I know that our hosts are able to see the luns on the new system, so zoning must be correct.

I'm still not 100% sure why there was a need for a second SVM as the 7MTT documentation seems to say you can consolidate vFilers to a single SVM, whereas the NetApp PS engineer working with me on this project seemed to think a second SVM was needed since we have 2 vFilers (7-mode HA controllers); I think that he was under the assumption that a second SVM was needed for the volume/lun mappings between the vFilers and SVM's, which may be the case if you aren't consolidating to a single SVM (which I haven't found the option for nor can I think of a reason why you wouldn't want to consolidate.)

Thanks again for the response, I'm still continuing to read through documentation.  This transition has me nervous to say the least, we are scheduled to attempt to complete the migration as of 7/16, fingers crossed everything moves over without any major issues.

[aborzenkov]

As a rule of thumb, to preserve 7-Mode identity NAS workloads need two SVM and SAN - one. This is due to single-image SAN configuration which allows you to consolidate LUNs while NAS identity is tied to controller.