2015-07-17 10:06 AM - edited 2015-07-17 11:55 AM
We currently have a FAS8020 8.3 cDOT cluster in our DR site, that is currently used for dev/QA storage as well as SnapVault destinations from our production site. We are in the process of migrating over from a FAS3250 at that site that is currently 8.2 7-mode. Currently, the SnapVault destinations are stored in a SATA aggregate attached to the FAS8020. When all migration from the FAS3250 is complete, we intend to reimage it to cDOT and pull it into the existing cluster and dedicate it to our SnapVault/SnapMirror backups. We then want to physically relocate the SATA aggregate that's currently attached to the FAS8020 over to the FAS3250 while keeping the volumes intact, similar to the aggregate import procedure that was available in 7-mode. Is this possible and is there a documented procedure for doing this?
2015-07-17 10:22 AM - edited 2015-07-17 11:54 AM
My apologies if I was unclear. We want to migrate a complete aggregate from one HA pair in the cDOT cluster to another HA pair in the same cDOT cluster, but keeping the volumes and the SVM intact (meaning not having to zero and rebuild the aggregate in the process and losing the data on the aggregate).
2015-07-17 11:53 AM - edited 2015-07-17 12:02 PM
Again, I am not trying to migrate this cDOT aggregate over to a 7-mode system. I am trying to physically move and migrate the aggregate to a different HA pair in the same cDOT cluster. I think your confusion is coming from the fact that the FAS3250 is currently a 7-mode system. That will not be the case at the time I need to move these disks. The FAS3250 will have been wiped, re-imaged with 8.3 Cluster Mode, and added into the cluster. So I'm looking for confirmation that the aggregate can be moved to a different controller pair, and imported with all volumes left intact.
2015-07-17 09:36 PM
2015-07-18 08:49 AM
I've researched the same concept myself for similar reasons - specifically to "merge" two independent cDot clusters together. It is simply not possible to do aggregate moves by physical shelf installation anymore.
The underlying reason is the metadata. An aggregate with the accompanying volumes in 7-mode are fully self described by the WAFL filesystem on the disks. In cDot, they are not. The cluster database, a copy of which is maintained on all nodes in the cluster, contains a ton of reference pointers as to what is where, what SVMs stuff belongs to, other relationship data, etc. There is no mechanism or utility that exists to map/merge 7-mode generic volumes into a cluster, building up the cDot metadata and ownership as you go.
I'm told by those with inside knowledge that cluster to cluster merge is something the DoT developers consider as a magic target if it could be automated mainstream, but 7-mode to cluster mode isn't even on the radar. With the existing data migration tools, and the fact that 7-mode is now officially EOL, physical aggregate migration between 7-mode and cDot isn't in the cards.
2015-07-18 09:57 AM
An aggregate with the accompanying volumes in 7-mode are fully self described by the WAFL filesystem on the disks. In cDot, they are not. The cluster database, a copy of which is maintained on all nodes in the cluster, contains a ton of reference pointers as to what is where, what SVMs stuff belongs to, other relationship data, etc.
That's not quite correct. Aggregate still contains enough information and there is tool to compare WAFL and VLDB and fix descrepances. May be this tool could even be used to introduce foreign aggregates and volumes into cluster. I do not have equipment to test it.
There is no mechanism or utility that exists to map/merge 7-mode generic volumes into a cluster, building up the cDot metadata and ownership as you go.
The question was how to move cDOT aggregate from one to another filer. At least that is how I understood it. Not how to import 7-Mode aggregate.
2015-07-18 06:10 PM
You're right on the move description - got a bit confused in the explanations. As long as it was in the same cluster I agree it in theory might be possible, even if it is totally unsupported.