"Heino" == Heino Walther hw@beardmann.dk writes:
Heino> Hi John Heino> I’m not sure if this helps…
Heino> I am also sure you can get the cluster running with half the nodes.
Heino> I am actually migrating between two HA-pairs as we speak.
Heino> We choose to setup a link between the nodes with two cluster switches, so the two HA-pairs is Heino> about 500M apart… (I’m not sure when latency becomes an issue)
Heino> But what we did was to add the two new nodes (temporary nodes) to the existing cluster, and we are Heino> then able to use the “vol move” operation to move volumes from one HA-pair to another, and of Heino> cause also the LIFs.
Heino> Works a charm so far. Huge NFS datastores have been moved with a hitch.
Heino> We did a “vol move start” with the “-cutover-action wait” Heino> option, which does the mirroring but waits until we tell it to Heino> do the cut-over… (in a service window)
Heino> There is however some “dedupe processes” which makes the Heino> cut-over very slow on larger volumes… it keeps telling us that Heino> it is waiting for a dedupe process to complete… (both systems Heino> are AFFs)…. But after 10-30 minutes it completes OK.
Maybe the answer is to turn off dedupe job(s) while you're in the pending cutover state? Or even before you do the initial copy? Not sure... it's an interesting question for sure.
Heino> Once we have emptied the source HA-nodes, we will move them to Heino> the new DC, and do it all over again back to the original Heino> system again…
Heino> So far no down time at all, which is nice 😊
Heino> I realize that you may not be a lucky as to where you have to Heino> move the systems 😉
Heino> So drive safely, and if you are running spinning disks, be Heino> prepared to replace a few as you startup the system 😉
Yeah, its almost all spinning disks, so I'm expecting to replace a bunch, but luckily I have a ton of spares from shelves not making the move to the new DC.
*grin*