A few general rules of thumb to go by:
1. Load-Sharing mirrors only ever benefit NAS volumes. SAN volumes have no need to be mounted into a namespace to function. 2. Best to create ONE LS mirror on each data aggregate in the cluster. 1. Sometimes this is nuts, like having 8 aggregates. At that point, I might defy the practice and maybe do one per node 2. Looks like it has been a while since I looked at those docs. It does show one per node now. When! 3. I personally have never had to utilize the LS mirror. It is tiny (1G per node per data SVM). 3. It is really not needed to update the LS mirror every 5 minutes. Even the FlexPod guides set it to 15. 1. You could always run a pre-script that does a "manual" snapmirror update-ls-set before any backup job to be safe (agreeing with your example in a way) 4. When you use the LS mirror, ONTAP defaults to **only** using the LS mirrors for client access. 1. To access the RW version, I think you need to mount: svm:/.admin 2. So, having the LS mirror on each node is actually a good thing for the clients. Stick with one LS mirror per node! 5. One SVM_root can have many replicas They are managed as a single group. You update one, all get updated. very easy to manage.
Bottom line: stick with one LS mirror per node. It is quote easy to setup (on the CLI, have never seen it able to be done in the GUI, of course, I have never looked either)
--tmac
*Tim McCarthy, **Principal Consultant*
*Proud Member of the #NetAppATeam https://twitter.com/NetAppATeam*
*I Blog at TMACsRack https://tmacsrack.wordpress.com/*
On Fri, Apr 23, 2021 at 12:54 PM John Stoffel john@stoffel.org wrote:
Guys,
We're getting ready to do a DC move, so I'm working to setup all my SnapMirror relationships to hopefully mirror all my data between my two pairs (all in one cluster right now). The idea being that if one pair doesn't make the move, we have our data elsewhere. No, we don't have any swing gear, the system is out of Netapp support, and we do have alot of spare space to mirror with. Whew. :-)
So I found the Netapp documents on "SVM Root Volume Protection Express Guide" from 2016 and I've started to implement it here, because if the worse case happens and one pair doesn't make it through the move due to damage or loss or catastrophe, I need to be able to bring up as much data as possible, as quickly as possible.
https://library.netapp.com/ecm/ecm_download_file/ECMLP2496241
I do have some questions for you all, to see what other people are doing, and what are current best practices and real life issues to watch out for.
First, I did change my setup so that I mirror every 5 minutes, instead of hourly as given in the quick guide. Since we use Netbackup to make clones of volumes to backup, that should hopefully work ok, but I worry that now I need to add in a:
snapmirror update-ls-set -source-vserver <vs> -source-volume rootvol
after I create a new clone, to make sure that the backup server will see this clone volume and junction path. Has anyone run into this issue and is your workaround to just do the update by hand, or do you just wait for the change to replicate?
Second, this document recommends one LS mirror per-head in a cluster. With a four node cluster, this seems a little crazy, especially since I've never had any problems when doing failovers during upgrades in the past. My main goal is to just have the mirrors on seperate pairs. What do people think? Is one rootvol and one rootvol_m1 mirror per VServer enough?
Third, if I go with just one LS mirror per-pair, I think it looks like I really need to make two mirrors, one for the source pair, and one for the opposite pair. Which seems like a pain to manage, increases the number of volumes and SM relationships to manage, etc. Since my main focus is NOT performance, since it's been working just fine without LS mirrors in the past, is just having one LS mirror good enough?
Cheers, John
Toasters mailing list Toasters@teaparty.net https://www.teaparty.net/mailman/listinfo/toasters