Aaron> I have not read anything yet on a transition method from Aaron> standalone volumes so they can be placed into an aggregate as Aaron> flexvols? i.e. Without adding more disk and doing some Aaron> snapmirror (volume or qtree). I guees I am talking about a Aaron> conversion(transmutation?) into the aggregate rather than a Aaron> migration.
From what I've read, you cannot convert (upgrade, update) old volumes into the new FlexVols or even into Vols on top of aggregates. You will need to move your data onto new disks.
Aaron> Please interrupt me right now if there is a way to do this.
Not that I know of.
Aaron> Say I have 10-12 volumes, all the same size, all 80% full, same Aaron> raid sizes (not DP), same disk geometry and speed. I want to Aaron> put them into one big aggregate. Can this be done without Aaron> actually creating a new aggregate from new disks beforehand?
If you can add another set of disks to match one of your existing volumes, then you could make them into an aggregate. Then you would make a new FlexVol (why not?) and SnapMirror/ndmpcopy/move the data over. Once it was over, you'd destroy the previous volume, then add those disks as a new raid group into the aggregate.
Continue until done. As you get more disks into the aggregate, you could probably start moving more volumes at a time as your free space grows.
Aaron> I can see a stepwise approach, but I am not sure if this will Aaron> be optimal.
I don't think there is an optimal way, though possibly what Acopia networks offers will help out. http://www.acopia.com
Aaron> 1) Partially populate your new aggregate with enough disks to allow Aaron> one traditional volume worth of data to be migrated to a new flexvol.
Yup.
Aaron> 2) Snapmirror and free up the old volumes disks, add these to Aaron> the aggregate.
Yup.
Aaron> 3) Repeat until all traditional volumes have become Aaron> flexvols in the new aggregate.
Yup.
Aaron> The main problem I see here is that the data will not be evenly Aaron> spread over the whole aggregate as intended. It will be Aaron> localised in raid groups, which is obviously marginally better Aaron> than the traditional volumes. Normal aging and WAFL Aaron> re-allocation will probably very slowly spread the flexvol Aaron> blocks throughout the raid groups, but my guess is that this Aaron> will take a very long time. Perhaps this is unavoidable?
There's a new tool to actually balance the data for you, so it's not as bad as it could be. Also, when you add a volume to an aggregate, the data can go onto any and all raid groups in the aggregate from what I read. So while the first RG will be unbalanced, over time as you migrate more RGs into the aggregate and move volumes over, data will spread out fairly evenly.
Aaron> Another question is how to deal with the complexity introduced Aaron> when all your traditional volumes were snapmirrored to one or Aaron> more other sites. Are we effectively talking a new snapmirror Aaron> baseline initialization here for the flexvols? This is a Aaron> nightmare because in a Disaster Recovery scenario we will Aaron> essentially be exposed during the initialization period and the Aaron> rate limiting step of a WAN link or snapmirror retrieve from Aaron> tape.
You might be able to snapmirror the new FlexVol, then make the SnapMirror into a FlexClone, and then make it writeable. Not sure though, it's something we're going to have to look into in detail ourselves.
Aaron> Has anyone thought this type of thing through or can point me Aaron> to reference documents?
Get the ones off the NetApp web site which talk about OnTap 7G. It's two PDFs which talk about it pretty well.
John John Stoffel - Senior Staff Systems Administrator - System LSI Group Toshiba America Electronic Components, Inc. - http://www.toshiba.com/taec john.stoffel@taec.toshiba.com - 508-486-1087