I have seen some contradictory information on migrating a CIFS vFiler in 7-Mode to a CIFS Server in an SVM in Cluster Mode and would like to see if anyone can provide some clarity.
First, the basics: I have six vFilers to migrate, each going into their own SVM. For all of them, we are preserving the identity of the vFiler - i.e. we want the name to stay the same once it is functional in Cluster Mode. For five of the six, we want to migrate the IP address as well. For one of them we want a new IP.
I was under the impression that in order to preserve the vFiler's identity, I had to create a temporary CIFS server on the Cluster Mode system during the 7MTT migration. At cutover, I would terminate CIFS on the 7-mode system, tear down the CIFS server on the Cluster Mode system, and recreate it with the identity of the vFiler from the 7-Mode system. We would then complete the migration.
However, having read tr-4336, page 61, and the 7MTT 2.0 Data and Configuration Transition Guide, page 58, it appears that I have it backwards. These documents appear to say that, before pre-cutover, I need to terminate CIFS on the 7-mode system, tear down the vFiler on the 7-Mode system, and recreate it with a temporary name before pre-cutover. I would then need to create the new CIFS Server on the cluster mode system using the identity of the original vFiler.
I would be interested in hearing from anyone who has performed migration of CIFS vFilers. The main things I'm trying to determine are:
Do I need a temporary CIFS Server on the Cluster Mode system, or a temporary vFiler on the 7-Mode system? Or do we need all three running at the same time - the original vFiler and a temporary vFiler AND CIFS Server?
If the latter, if the goal is to preserve the 7-Mode configuration information so it can be transitioned, how is that possible if I am creating a new vFiler, presumably using the same root volume as before, which wipes out the original configuration?
In 7-Mode, individual controllers, NetApp vFiler® instances, and HA pairs result in clear boundaries for how workloads can be divided between systems or how they can be consolidated within the same HA pair. In short, a silo-based approach dictates how much can be hosted on any given storage system.
Clustered Data ONTAP delivers a single namespace that enables a workload to be scaled across one, some, or all of the nodes in a cluster. This is possible because a storage virtual machine can contain a collection of flexible volumes that can reside on any node in the cluster.
The primary consideration for clustered Data ONTAP and namespace design is how the existing systems will be migrated to storage virtual machines. If possible, it is best to align with the forward-looking architecture of the clustered Data ONTAP system that will service the workloads moving forward.
In some cases, however, it may be easier to migrate each 7-Mode controller into a separate storage virtual machine. Although this might seem easier, it is not optimal because volumes cannot be nondisruptively moved between SVMs in clustered Data ONTAP. As a result, it is best to verify that volumes are migrated
Both TR-4336 and the 7MTT guide provide the same general guidance:
Clients connected to the 7-mode CIFS server must be disconnected
The 7-mode CIFS server should be reconfigured to a temporary name (to eliminate conflicts with the new clustered Data ONTAP CIFS server)
Then create the new CIFS server (using the original 7-mode CIFS server name) on clustered Data ONTAP
You don't need to create a temporary CIFS server. Where did you see the reference to terminating the 7-mode CIFS server (rather than just the client connections) or tearing down the 7-mode CIFS server (you do need to reconfigure the name).
As I understand it, from the 7MTT guide, the instructions are:
Before precutover, reconfigure the CIFS server on the 7-Mode by using a temporary CIFS identity. This allows the original CIFS server identity to be configured on the SVM. Ensure that CIFS server is running on the 7-Mode system during the precutover operation with the new temporary identity. This is required to read CIFS configurations from 7-Mode during precutover.
Configure the CIFS server on the target SVM with the original 7-Mode CIFS identity.
"reconfigure the CIFS server on the 7-Mode by using a temporary CIFS identity"
It had not occurred to me that this might mean simply rename the vFiler. But won't the fact that DNS is still pointed to the IP address be an issue? And I'm assuming the AD account need to be removed and re-created with the new identity in cdot? Just want to ensure we're covering all the bases!
Thanks John. So, to summarize, here are the steps we would perform prior to cutover:
Stop all connections to the vFiler.
Rename the vFiler to a temporary name, update DNS to point the IP to the temporary name, and remove the AD computer account/add a new AD computer account with the temporary name
Once migration is complete, THEN turn off the original vFiler, update DNS to point the IP to the permanent name again, remove the temporary AD computer account, and join the new CIFS Server to the domain
On the second bullet, would it be better to have a temporary IP to go with the temporary name? That way no DNS/AD changes are needed (I would assume). We just change the vFiler name and CREATE a temporary DNS entry and AD computer account to go with the temporary name. Then after cutover completes, we just turn off the temporary DNS/AD/vFiler, and create the CIFS Server with the original identity on the cdot system.
So I began our test this morning, and it didn't work. The 7MTT did in fact require that a temporary CIFS Server be configured on the destination SVM, which I had removed. Instead, I had renamed the 7-Mode vFiler to a temporary name before attempting cutover. Any ideas here? Do we actually need TWO temporary names/IPs, one to set up a temporary vFiler name, and one to set up a temporary CIFS Server?
FYI I think I've figured it out. Apparently, after renaming the CIFS Server on the 7-mode system, the CIFS Server in Cluster Mode should be configured with the original vFiler identity BEFORE cutover. I had been under the impression that this final step should only be done after transition is complete. Will retest later today.
For the record if anyone searches this topic, that worked great! Share definitions are even copied over, which I've not seen documented anywhere - apparently this capability was added in a recent revision of the 7MTT.
Did you clear the credential cache, I saw that as a required step opn the source vFiler when you give it the temporary/new name, maybe its not always needed ot just generates erors in logs. Just interersted to know if you did that step.