Re: Moving a 4 node cluster in two pairs?

Another idea would be to use SVM-DR
Setup a cluster peer. Then create the destination SVM and create a vserver
peer between the source and destination.
If you do not wish to mirror all volumes, I believe there is a per-volume
option you can modify to prevent an unwanted snapmirror relationship in the
SVM-DR.
If the networking is the same between both locations, you can even allow
the SVM-DR to copy the identity (LIFs, Addresses, etc)

You could then "cut over" to the new location and use it.

Make sense?

--tmac

*Tim McCarthy, **Principal Consultant*

*Proud Member of the #NetAppATeam <https://twitter.com/NetAppATeam>*

*I Blog at TMACsRack <https://tmacsrack.wordpress.com/>*



On Wed, Mar 3, 2021 at 2:22 AM Sebastian P. Goetze <[email protected]>
wrote:

> just to add to Heino: I had a student in one of my courses just lately,
> that moved his datacenter some 4-5 km with exactly this setup (4 cluster
> switches and good redundant connectivity) and some swing gear, if I
> remember correctly, because he didn't have enough capacity to completely
> evacuate a pair before the move. Completely non-disruptive, nobody noticed
> anything...
>
> Sebastian
>
>
> sent from my mobile, spellchecker might have messed up...
>
> On Tue, 2 Mar 2021, 19:36 Heino Walther <[email protected]> wrote:
>
>> Hi John
>>
>>
>>
>> I’m not sure if this helps…
>>
>> I am also sure you can get the cluster running with half the nodes.
>>
>> I am actually migrating between two HA-pairs as we speak.
>>
>> We choose to setup a link between the nodes with two cluster switches, so
>> the two HA-pairs is about 500M apart… (I’m not sure when latency becomes an
>> issue)
>>
>> But what we did was to add the two new nodes (temporary nodes) to the
>> existing cluster, and we are then able to use the “vol move” operation to
>> move volumes from one HA-pair to another, and of cause also the LIFs.
>>
>> Works a charm so far.  Huge NFS datastores have been moved with a hitch.
>>
>> We did a “vol move start” with the “-cutover-action wait” option, which
>> does the mirroring but waits until we tell it to do the cut-over… (in a
>> service window)
>>
>> There is however some “dedupe processes” which makes the cut-over very
>> slow on larger volumes… it keeps telling us that it is waiting for a dedupe
>> process to complete… (both systems are AFFs)…. But after 10-30 minutes it
>> completes OK.
>>
>>
>>
>> Once we have emptied the source HA-nodes, we will move them to the new
>> DC, and do it all over again back to the original system again…
>>
>>
>>
>> So far no down time at all, which is nice 😊
>>
>>
>>
>> I realize that you may not be a lucky as to where you have to move the
>> systems 😉
>>
>> So drive safely, and if you are running spinning disks, be prepared to
>> replace a few as you startup the system 😉
>>
>>
>>
>> /Heino
>>
>>
>>
>> *Fra: *Toasters <[email protected]> på vegne af John Stoffel
>> <[email protected]>
>> *Dato: *tirsdag, 2. marts 2021 kl. 19.24
>> *Til: *[email protected] <[email protected]>
>> *Emne: *Moving a 4 node cluster in two pairs?
>>
>>
>> Guys,
>> We're getting ready to move our 4 node FAS8060 cluster to a new data
>> center.  As part of our due diligence, we're thinking that we would
>> snapmirror the most critical business volumes between the two pairs.
>>
>> The idea would be that if the truck holding pair A+B doesn't make it
>> for some reason, we can still bring up the cluster with nodes C+D and
>> still have those snapmirrored volumes available to continue working.
>>
>> So my questions are:
>>
>> 1. Can I boot a cluster with half the nodes missing?  I'm sure I
>>    can...
>>
>> 2. Has anyone else had to do this half assed method of shipping DR?
>>
>> Cheers,
>> John
>> _______________________________________________
>> Toasters mailing list
>> [email protected]
>> https://www.teaparty.net/mailman/listinfo/toasters
>> _______________________________________________
>> Toasters mailing list
>> [email protected]
>> https://www.teaparty.net/mailman/listinfo/toasters
>
> _______________________________________________
> Toasters mailing list
> [email protected]
> https://www.teaparty.net/mailman/listinfo/toasters

_______________________________________________
Toasters mailing list
[email protected]
https://www.teaparty.net/mailman/listinfo/toasters