#Physically moving disks with aggregates on cDot. It there an official way to do it?

1 messages · Page 1 of 1 (latest)

final pilot
#

We have two clusters who need to mirror a few large volumes between sites with limited bandthwidth. So we would like to sync up the mirrors on disks in a new shelf that we connect to the local system. Then we would like to offline the aggregate, disconnect the shelf and move it to the destination. This is/was very easy to do on good old 7mode.
But if you do this on cDot you end up with the "debug vreport fix -type aggregate -object aggr..." in order to bring the new aggregate into the destination cluster, the do the same procedure to the volumes.
This data is only CIFS/NFS so no LUNs.
There is a change that we would like to enable volume encryption on the destination volumes... I guess this will add a bit of complexity ?
The data we are moving is only backup data, so if we end up messing up this procedure it's not a big loss, we will just clear the disks and start over, and will have to wait for the mirrors to resync... (which will take weeks...) 🙂
Any suggestions are welcome...

fallow ruin
#

I don't think moving disks between clusters is supported... I wouldn't do it with production data unless someone at NetApp explicitly tells you to and also takes responsibility 😉

swift forum
#

I think smtape is still a thing, right ? Snapmirror to Tape.

You can also just throttle the snapmirror traffic globally on the destination:

options -option-name replication.throttle.incoming.max_kbs 60000 -> set to your limit

#

That option is dynamic meaning whatever you set it to and whenever you set it, it takes effect immediately.

I’ve watch snapmirror traffic go from full pipe load to the limit (system node run -node xx sysstat 1 -> Watch the network in traffic)

final pilot
#

The problem is that we need to push about 200TB of data through a shared 1-2Gb/sec line... which will take forever... so the snapmirror to a local aggregate, then move the disks behind this aggregate to the destination is a much more appealing option... I think it's sad if this cannot be done... and I think we might ask NetApp Support about this although my guess is that this will result in nothing 😉 and we might just give it a go outselfs and take the risk 😉

fallow ruin
#

the only way you could pull this off is by using a complete cluster as transfer device, not just the disks, i.e. slap a controller in front, do the snapmirror baselines, move the transfer machine, do snapmirrors to the destination and then do incremental updates over the network

#

this works perfectly and is supported

swift forum
#

We used to use the old FAS250 for just this!

#

Sorry: F250

fallow ruin
# swift forum Sorry: F250

I think you do mean the FAS250 😉 the original shrunken head, the Tsantsa. Cute little system, I have one still running in my basement from time to time for backups...

#

The F series had the F200/F300/F500/F630/F700, but no F250 AFAIK

#

ah and the F75

#

I think we have a bezel from an F75(?) somewhere...

final pilot
#

Yeah I have a few FAS2750's somewhere, I guess we will be using them then... Only issue is the 200TB left over capacity after we have migrated... anyway.. I my self started with the F520... ONTAP on Floppies and Alpha CPU... yeah I feel old now 😉

swift forum
#

I started on the 400 (tower, non-hot-swap drives) and then the follow on 1400 (rack mount with hot swap). There’s really old