We are considering adding a new pair of HA-nodes into our cluster. And for whatever reason it would be useful for us to move two DS460c shelfs to these new nodes, keeping the aggregates on them. There are no root-aggregates on them, just two data aggregates, one for each of the "old" nodes... We are of cause aware that this requires down time, but it would save us a lot of data migration if possible... I my own mind I would think that this should be possible because the aggregate is known in the cluster... but not sure... any ideas of how to "hack" this? 😉
#Relocate aggregate to non-local node in the same cluster?
1 messages · Page 1 of 1 (latest)
Not sure if that's actually supported since an aggr can only be owned by the nodes in the HA-pair where it's shelves are connected to (excluding MCC usecases).
It should be possible though by reassigning disks to the new system IDs of the new nodes.
Kind of comparable to the "Upgrade by moving storage" workflow: https://docs.netapp.com/us-en/ontap-systems-upgrade/upgrade/upgrade-by-moving-storage-parent.html
But you would get stuff like this https://kb.netapp.com/on-prem/ontap/Ontap_OS/OS-KBs/Duplicate_aggregate_after_moving_disk_shelf and need to manually fix it (debug vreport, etc).
If you really need the data on the aggrs of these shelves I wouldn't dare to do this without creating a case.
It's an interesting usecase though, I'm actually surprised I've never done that yet...
Regarding support for this: https://kb.netapp.com/Support/csm-sam/What_are_the_key_considerations_for_moving_storage_between_storage_systems
"The only supported way to physically move shelves with data intact is to follow Upgrade Controller by Moving Storage documentation.
Physical movement of some shelves that host aggregate/volume data is not a supported activity."
feel free to test it in the Lab 😉 I'd also be interested to see if it works
We don't have any 4-node cluster currently, and I know your answer to that already 😜
yeah, "someone" decided to cable all our systems as switchless cluster to remove the switch 😛 but I think we could still do that somehow when the systems are unused for a few days