tardy tree
Hi all,
I have a pretty large Cifs volume on a A400.
Would like to migrate to a flexgroup. Is it an option to do this with a local snapmirror to the new flexgroup volume?
I already found out the converting and Rebalancing is not recommended
Thanks!
Martijn
hollow mural
I don't think you can SnapMirror a FlexVol to a FlexGroup. The only way I can see that is not a conversion is client-side copy
halcyon current
SnapMirror will not work. You will need a client-side copy mechanism or NDMPCopy for that.
tardy tree
Alright thanks!!
Strange thought: conversion and then snapmirror to balance the blocks? Delete the source afterwards.
dreamy lintel
Won't work either.
There is reblanace,
but it has nothing to do with snapmirror.
it's also not recomneded to run rebalance after a conversion.
tardy tree
Ok, I will use xcp then to copy the data to the new flexgroup and create a cut-over moment
fallow ledge
If you run into file name issues, ndmcopy may end up better. Has forever incremental
tardy tree
Maybe I was not clear.
This my idea:
restive thistle
i don't think this will get you there. There won't be any distribution of data to new constituents on the destination because of snapmirror
if you don't encounter lots of restores from snapshots, i'd just convert the volume and let the internal flexgroup algorithms fill up the new constituent volumes. You can keep the conversion snapshot around for a while for pre-conversion restores. It all depends on what the volume is used for, in the end.
it'd be nice to know why rebalance "after" conversion isn't recommended.
hollow mural
yeah, SnapMirror on a FlexGroup is basically a bunch of separate SnapMirrors on the constituents, so that won't help you at all in your situation
tardy tree
Thanks all!! Love the interaction and feedback!!
fallow ledge
Agreed here. You need an actually “copy into” the flexgroup to properly distribute. Hence, NDMPcopy or XCP. In both cases, create the new fg. Set up the initial transfer. Do a handful of incrementals to gauge how long the update will take. Then keep the updates happening and plan the cutover.
If it’s cifs, you can stop the share, do an update then modify the share to point to the new fg. Confirm then delete the original
hazy turret
it'd be nice to know why rebalance "after" conversion isn't recommended.
Because rebalance introduces extra overhead. Rebalance is great if you have a FlexGroup used for say VMware datastores or databases because they are large files. But if you have a large file spread with millions or billions of inodes it hurts performance.
restive thistle
Because rebalance introduces extra overhead. Rebalance is great if you have a Fl...
there is always going to be that overhead anyway as the distribution algorithm tries to balance writes among the constituent volumes, although I don't know how much it knows about adhering to filesystem structures internally if possible. The "one-time" reblance is going to give you a bug snapshot diff probably, but I don't see the problem in the long run. Not running reblance is probably just going to overload the second (if one is going from 1 flexvol to a flexgroup of 2 volumes) volume with all writes until they are balanced, more or less.
hazy turret
No it's not that kind of overhead...
https://docs.netapp.com/us-en/ontap/flexgroup/manage-flexgroup-rebalance-task.html
Note
You should be aware that FlexGroup rebalancing degrades system performance when large numbers of files are moved as part of a single rebalancing event or over multiple rebalancing events because of the creation of multi-part inodes. Every file moved as part of a rebalancing event has 2 multi-part inodes associated with that file. The larger the number of files with multi-part inodes as a percentage of the total number of files in a FlexGroup, the greater the performance impact. Certain use cases, such as a FlexVol to FlexGroup conversion, can result in a significant amount of multi-part inode creation.