vfiler migrate cutover - How long does the cutover take?

[MSANDONASSGA]

quick question for anyone who has done a vfiler migrate. 

Assuming all goes as planned, how long does the cutover (vfiler migrate complete) generally take to finish?

Matt

[scottgelb · Accepted solution]

There is no guarantee or set time for the migrate to finish.  For a guaranteed time (120 seconds or less) Data Motion for vFilers is used from the NetApp Management console and it manages the migration.  A manual vfiler migrate takes as long as it takes to complete mirrors for all volumes in the vFiler.  So if the snapmirror updates take 5 minutes then roughly that time plus the time to stop the source, destroy the source vfiler and then activate the target.  I have seen it take 60 seconds and in another case 30 minutes with a customer with millions of small files.  Since it uses async snapmirror for the final update the way to keep it fast as possible is to have ALL mirrors very close up to date with low lag times prior to running vfiler migrate complete.

So a good estimate (but no guarantee) is to keep your mirrors within a minute or so lag time then see how long each update takes.  While the update runs with vfiler migrate complete the source vfiler is stopped and there is no revert back (other than manually recreating the vfiler which can be done with vfiler create -r to save having to resetup configuration by specifying only the root volume of the vfiler.).  It depends isn't the best answer but in this case it fits depending on the rate of change.  Do you have a baseline of time for all snapmirrors of all volumes in the volume? That will be a good estimate, then add 20-30 seconds maybe for the vfiler activation and registration.

[MSANDONASSGA]

thanks Scott.  there's only one volume and will probably only need a minute or so to get in sync so this estimate is just what I needed.

Much appreciated.

Matt

[scottgelb]

Cool... you could also run a test... create a FlexCone of the volume...create a new test vfiler... then run migrate configure and migrate complete on the target to get timing for the same volume...but without affecting the production one.

[MSANDONASSGA]

Scott,

since you seem to have a great handle on this topic, perhaps i can ask you one more question.

suppose i manually do a snapmirror of the vfilers volumes outside of the vfiler migrate process.  Is there a way to bascially do just the "vfiler migrate complete" part of the process without having to do the SM copy over? 

thanks again.

Matt

[scottgelb]

You can manually update mirrors with snapmirror update. As long as vFiler migrate is configured prior. I usually run manual updated before the migrate complete.

Sent from my iPhone 4S

[MSANDONASSGA]

thanks Scott looks like i could also do this:

manually snapmirror vfiler vol0 and associated volumes.

down source vfiler

update SM on mirrored volumes.

break snaps

run vfiler create -r

Matt

[scottgelb]

Correct… you could manually mirror everything then manually create the vFiler on the target like that. Just make sure the IPspace is there and then you will need to ifconfig the network with the IP the vfiler uses… don’t use the setup command or it will wack a bunch of files (hosts, exports, resolv.conf, etc.)… once you vfiler add -i IP (and vfiler remove –i ip if you are using a different network) just ifconfig that same IP you assigned to the correct interface and it will bind (and update rc and hosts of course).

[naimm]

Scott, are you able to answer the question I have, which is similar to what Mathew asked.

- Can we set up snapmirror manually prior to the vfiler migrate tasks?

Therefore eg set up snapmirror, have the mirrors in place and then start the vfiler migrate process. Therefore, if the mirrors are in place and then the vfiler migrate is run, will this process in any way remove the current mirrors in place and start a new baseline, etc? thanks.

[scottgelb]

Unfortunately, vfiler migrate sets up the mirrors for you and no option to use existing mirrors... So if you haven't create mirrors yet, you can vfiler migrate and let it create the mirrors to use for the cutover.  If you already have the mirrors and can't recreate them easily, vfiler dr does have the ability with the "-u" option to use existing mirrors.... so you could use vfiler dr instead of migrate to do the cutover...it would be a quick outage instead of a migrate...stop the source vfiler, vfiler dr activate the target then do cleanup work after...but still a quick way to cutover.  In some cases (this is a good case for it) you can use vfiler dr to do a cutover instead of migrate.