#SVM Migrate Question

1 messages · Page 1 of 1 (latest)

frank fog
#

Hi there, couple quick questions on SVM Migrate. I will migrate a CIFS SVM to a new cluster in about a month. I'm going from an AFF-A700 on 9.14.1P15 to whichever OS the FAS2820 will have on it. First; do I need to upgrade the A700 to match the 2820 or can I go from one version to another? Second, I know I'll need to set up ports/VLAN tags/broadcast domains in advance on the 2820, but do I also need to create a LIF? I ask because online documentation says "Both the source and destination clusters must have at least one interface that has access to all the migrating SVM’s networks, otherwise the migration precheck will fail." Thanks!

tulip falcon
#

You really should updgrade the A700 to 9.16.1P10 and make sure the FAS2820 is also on the same release. (I work with a lot of air-gapped customers and currently prefer 9.16. Your scenario may allow you to use 9.17)

#

vserver migrate currently does not support FlexGroups. If you use FlexGroups, you may need to use SnapMirror SVM (aka SVM-DR) with Identity Preserve in order to do the migration.

#

vserver migrate will validate Layer-2 connections as a pre-check. So, you should have the same VLANs/Networks/ipspaces on new system as the source

#

If I have the time, I like to create a TEST LIF in the admin svm to make extra sure the network is behaving as expected, then delete the TEST LIF.

#

The process of "vserver migrate start" will take care of just about everything:
replicate all volumes (NAS Only!), create identical copies of LIFs - that are down during the copy. After the volumes are replicated, ONTAP will work with verifying cutover and then shut down source, do a quick update and then bring up the destination. Finally, it will delete the source.

elder mulch
frank fog
#

Thanks @tulip falcon , good advice on the versioning, and that's pretty much what I was thinking on the migration steps. This is a simple CIFS Server with one large volume. I assume it also copies over share and NTFS permission definitions, right? Also, I don't believe the source LIF is offline during the vserver migrate, otherwise the CIFS Server would be down the whole time. Definitely planning to test, just gathering preliminary info. Thanks for commenting!

#

Never done it with NFS datastores, but typically I just set up new datastores and VMotion the VMs over ... seems easier to me.

elder mulch
#

Yes it copies the NTFS permissions and shares...

tulip falcon
#

Personally, I would NOT do this with the SVM hosting any virtualization products (vmware, proxmox, hyper-v, etc)

#

Most times it is just easy to to do a vmotion (or equivalent) from old storage to new

frank fog
#

Thanks @elder mulch ! Thanks to both of you for the feedback!

tulip falcon
frank fog
#

Thanks @tulip falcon ! Not a FlexGroup, just a standard FlexVol so we should be good. And plenty of space.

frank fog
#

Does SVM MIgrate also migrate snapshot policies and schedules, or do they need to be recreated at the target?

candid cypress
#

Schedules must be already created. Snapshot policies will be migrated but the will have the ending -MIG

ashen copper
#

Beginning with ONTAP 9.11.1, job schedules used by the source are replicated automatically during migration.

frank fog
#

Thanks @OG1. Do policies still get migrated with -MIG at the end as Falcon mentioned? Or do they just get migrated as-is now?

candid cypress
#

After migration, local snapshot policies have the extension -MIG that might break some automation. You should search for this extension and rename the policies and needed.

frank fog
#

Ah, super-helpful, thank you @Falcon667!

candid cypress
#

You are welcome. We are currently testing svm migrate from a metro to a metro and found some missing points in the documentation. @tulip falcon how is your experience with svm migrate and cifs? We plan to consolidate a metro with a lot of cifs svms and I‘m a bit skeptical

tulip falcon
#

Just kicked off another last night.

frank fog
#

I notice SVM Migrate also migrates replication jobs if I understand correctly. I have a job for the volume in the SVM I'm migrating, however I'll need to give it a new replication target when it 'arrives' at it's new location. I take it that I will need to break the migrated replication job and then establish a new one?

candid cypress
tulip falcon
#

yep. it does some snapmirror stuff on the back but evverything works. it was cutover to the new system when we came in this morning\

small fox
#

My favorite thing is that it also migrates the AD domain infromation. No need to rejoin each svm to their respective domains. Saved me so much time and hassle

tulip falcon
#

Or the keeping of snapmirror destinations

#

That’s a super bonus not having to set that back up

elder cargo
elder mulch
#

I guess it all depends on how many volumes you have in your SVM... in our case it's like 30 volumes of about 10TB each... not sure if I would dare pull the trigger on that 😉

elder cargo
#

In our case, one of SVM have 23 volumes, around 47TB used; the second we migrated was around 44TB, 21 volumes

NFS protocol

small fox
elder cargo
#

@small fox : yes

eternal garden
#

Thank you guys

elder mulch
#

Just a question regarding SVM Migration and LIFs... We have a source which is using the port e0e-50 for NFS... on the destination we do not have e0e, but e4c+d yet we would like to set this up as a ifgrp LACP, so it would be a0a-50 is the migration able to figure this out? We also have a mgmt lif on e0c-10 which we would like to mive to a0a-10... is it just as easy as to create the ifgroup/vlan and then do the migration? 😉 Can you verify which ports the migration will pick? Potentially you could have more then one port on vlan 50... 🙂 We are migrating from 9.16.1 to 9.17.1.. would it make sense to level the versions? (in the docs it states it should just not be more than two version appart..)

tulip falcon
#

There are check for layer 2 compatibility. ONTAP will check for vlan 50. Setup your ifgrp and create the a0a-50 ports. Migrate will find and use them

You will also have less issues on the save release. I’ve done a bunch on the save and different versions.

I prefer when possible to level set the versions.

Sometimes bit possible. A320 can only go to 9.14. So I set the destination to 9.16 and go

In either case be sure tot are on the most up to date patch version on both sides

elder mulch
# tulip falcon There are check for layer 2 compatibility. ONTAP will check for vlan 50. Setup y...

OK, sound doable 🙂 And I think the source can be upgraded to 9.17.1... even though it is a Lenovo branded... And yes I know this isn't supported etc. etc. etc. 🙂 We will take this risk, because the alternative is a nightmare of snapvault relations with long retentions which has to be resynced etc.. We know that SnapVault between this Lenovo system works against a NetApp destionation without any problems 😉 so I am fairly sure it will work ok...

fringe flare
#

Wanted to add one more detail to those planning to do the SVM migrate. By default, it will migrate, cutover and cleanup all automatically, which is cool, but if you want more control over the cutover, cleanup etc, to have that - just in case backout plans, you can disable the Auto nature with the these switches when you start the migration - -auto-cutover and -auto-source-cleanup to false. You will have to do it manually when the source and target are in sync, but the nice thing is , you can choose to do the cutover at a certain time , if you have change ticket etc. The source will be stopped when you do the cutover, so it will serve as a backup just in case something didn't work and you wanted to go back

elder mulch
#

Is there any way you can control on which aggregate the volumes will be migrated?

tulip falcon
#

Vserver modify -vserver xx -aggr-list ag1,ag2

elder mulch
tulip falcon
#

Pretty sure ONTAP tries to do likes for like on the replication when possible

candid cypress
elder mulch
#

Thanks, I will look into that...

elder mulch
# candid cypress You can use REST for that. There you can specify every aggregate per volume and ...

OK, as I run the vserver migration command it fails with what looks like a space related issue, even though there should be enough space on the destination aggregates. But not sure how much "headroom" is requires? I have two destination aggregates with 21TB each. And I have 4 volumes that needs to be migrated of 17TB, 7TB and 5TB... I have then tried to start this using REST Swagger UI... but I get an 202 reply, so not sure it works... also the example in swagger has a lot of UUIDs which I guess isn't required? I am using the "volume_aggregate_pairs" and create one per volume, I don't think it supports this with one aggregate and several volumes (for some reason)... but as mentioned I don't see mich as I execute the REST API... I also tried with "check_only: false" and it doesn't start anything up... ?

#

Here is the json..: { "auto_cutover": false, "auto_source_cleanup": false, "check_only": false, "destination": { "volume_placement": { "volume_aggregate_pairs": [ { "aggregate": { "name": "a20_01_NVME_SSD_1", "uuid": "9065fa75-a614-4a65-8013-e2aa89ef7e57" }, "volume": { "name": "GEODM5NFS02", "uuid": "c7f5753d-d377-11eb-a306-00a098f50bfa" } }, { "aggregate": { "name": "a20_02_NVME_SSD_1", "uuid": "691ee17d-894f-410a-a04f-53aba5812fc5" }, "volume": { "name": "GEODM5NFS01", "uuid": "988f9d6a-d377-11eb-80f7-00a098f50cbf" } }, { "aggregate": { "name": "a20_02_NVME_SSD_1", "uuid": "691ee17d-894f-410a-a04f-53aba5812fc5" }, "volume": { "name": "GEODM5NFS01_PT", "uuid": "55fea399-3016-11ed-80f7-00a098f50cbf" } }, { "aggregate": { "name": "a20_02_NVME_SSD_1", "uuid": "691ee17d-894f-410a-a04f-53aba5812fc5" }, "volume": { "name": "GEODM5NFS_root", "uuid": "8de8ed6a-d335-11eb-80f7-00a098f50cbf" } }, { "aggregate": { "name": "a20_02_NVME_SSD_1", "uuid": "691ee17d-894f-410a-a04f-53aba5812fc5" }, "volume": { "name": "GEODM5TEMP", "uuid": "fdd750ba-e23a-11ef-8ad6-00a098f50cbf" } } ] } }, "source": { "cluster": { "name": "GEODM5" }, "svm": { "name": "GEODM5NFS" } }, "throttle": 0 }

#

hmmm removed all the uuid's which was currect btw. but then it seems to work and we are now migrating... 🙂

#

I love the fact that the migration is "kinda" invisible on the destination... you can see the vserver and volumes has been created.. but the CG created isn't shown... and nothing under replication... 😉 but it's moving along at pretty much line speed 😉

candid cypress
#

Go to diag mode and use snapmirror show -expand

#

There you see how much is already replicated like a normal snapmirror

#

We have migrated around 1TB per 30min

#

As soon all data is copied, then it starts with the snapshots. Depending on the amount of snapshots and size this can take some time

elder mulch
#

Yep migration worked flawlessly.... maxed out the two interconnects while transfferig, can't ask for much more than that 😉