Protecting Root Volumes With LS or DP?

[TMADOCTHOMAS]

Hello,

For years I've protected our SVMs with load sharing mirrors as recommended by NetApp best practices. However, I just ran across some documentation / articles that imply this can be done with standard DP protection jobs just as well (see below). More critically, the first article mentions this: "The first difference, if the decision is to use LS mirrors, is an extra step that must be performed to update the namespace.  Changes with shares, exports or new volumes will not be immediately reflected in the namespace.  Updating a LS mirror set is required if you want these namespace changes reflected and visible to all clients." This seems to imply that updating a DP mirror set is not required to update permissions! If that is accurate, I would want to switch to DP immediately as this limitation has caused huge headaches with a 3rd party app (Veeam) unable to see permission changes quickly enough. Does anyone know the answer to this? Thanks in advance!

https://red8.com/resources/knowledge-base/configuration/netapp-protecting-svm-root-volume/

https://library.netapp.com/ecmdocs/ECMP1196906/html/GUID-3A6C32A1-EBE5-4F5C-A3EA-837BF6246A83.html 

[aladd]

What the article is describing is in relation to load sharing mirrors vs SVM-DR.

Load sharing mirrors are available as additional points of contact for read only data that share a namespace.

Whereas the SVM-DR is more like an active/passive relationship that requires intervention to bring live in an event the origin SVM is inaccessible. these can also be used in tandem, and may make a difference for what you're trying to accomplish. (caveat, LS mirrors cannot be used in the SVMDR destination, but can on the source.)

While LSM stretches across a cluster, SVM-DR can span multiple clusters for catastrophic failure events that may impact a datacenter or the cluster.

Additional resources:

https://kb.netapp.com/Advice_and_Troubleshooting/Data_Protection_and_Security/SnapMirror/Can_LS_Mirror_be_setup_on_an_SVMDR_destination

additional information on SVMDR

https://docs.netapp.com/us-en/ontap/data-protection/snapmirror-svm-replication-concept.html

update to LS mirrors. Now used for temp RO access for an inaccessible SVM root, or can be promoted for full RW access:

https://docs.netapp.com/us-en/ontap/data-protection/manage-snapmirror-root-volume-replication-concept.html

[TMADOCTHOMAS]

Thanks @aladd . Neither article mentions SVM-DR so I'm not sure why you are saying that's what it's referring to? We don't use SVM-DR at any rate so it's not relevant to this discussion. 

The last link you sent was helpful as it provided one key detail: "the load-sharing mirror automatically provides read-only access to root volume data" if the root volume is unavailable. So I guess that's a key difference between LS and DP.

Here's another article I found that goes in even more detail on the different approaches.

https://lists.archive.carbon60.com/netapp/toasters/17451

Still looking for official NetApp documentation on the DP approach vs. LS. Apparently it can be done but I can't find clear 'official' documentation on it.

FYI I mistakenly clicked "Mark as Solved" 🙂 when I intended to just click Reply. The issue isn't necessarily solved at this point. 

[TMADOCTHOMAS]

Just determined how to unmark it.

Having read a lot of documentation, clearly NetApp points everyone toward the load sharing approach as the best practice. If I understand correctly, the reason is that it provides a seamless continuous experience if the root volume has a problem. Having said that, our LS volumes replicate every 5 minutes so I'm not sure if the problem would be caught quickly enough to stop the issue from replicating to the LS copy!

Regarding the DP approach, would still like to hear more about it "officially" from NetApp, and determine if it's a feasible alternative. I don't want to eliminate the resiliency, but I also have experienced numerous problems over the years due to delayed permissions under this setup.

[scottgelb · Accepted solution]

This is a great topic and one coming up more often with changes. The best practices have changed over the years where we originally created an LSM on every node, for example 12 mirrors per SVM on a 12-node cluster including the home node of the SVM root (vsroot). Then the best practice was 2 mirrors.  Now, the latest docs (I really like how the docs team keeps live docs now...so good) are just ONE LSM now per SVM. Here is the latest link 

https://docs.netapp.com/us-en/ontap/data-protection/create-load-sharing-mirror-task.html 

The doc you listed for DP (XDP by default now) is one I used to refer to, and I used to recommend XDP mirrors to protect SVM root since it was supported. The benefit is you do not have to update mirrors immediately to update the namespace, but a downside is you have a two-step method to make the XDP mirror root with "snapmirror break" and "vol make-vsroot".  

I went back to using LS Mirrors for these reasons

1) if SVM root goes down, the LSM keeps working in it's place readonly

2) A single "snapmirror promote" command makes it active

3) I have hit some bugs on make-vsroot (old root volume stays in the junction-path as a ghost entry). Working an escalation on that now.

You are exactly right, that a drawback is you have to update the LS Mirror for any change to an export, cifs share, junction-path, etc. Some customers use the "5min" schedule on the mirror. I like to leave it hourly and run "snapmirror update-ls-set" after any changes.  Maybe the 5min schedule will work better for you if there is no way to script the update, but I think you should be able too add the snapmirror update-ls-set to the Veeam workflow?

Now for my wishlist... if any PMs or ONTAP developers see this 🙂 Make this an internal ONTAP process in the RDB. Take the root junctions and keep them in the database... if make-vsroot is done, just push it to any SVM root volume. Or even better, maybe SVM root (vsroot) could be a virtual concept... make the "/" junction-path a database entry. Or automate LSM creation from the SVM create workflow for NAS SVMs. I'd prefer it a hidden "feature" we don't even see or worry about. 

[scottgelb]

Another note, with SVM root volume encryption support now in newer ONTAP, I had an issue resyncing XDP mirrors when ONTAP software encryption (NAE) was used and had to re-create from scratch. LSM did not have these issues, so one more reason I use LSM only now for NAS root volume protection.

[scottgelb]

And in all my years doing this, I have NEVER had to restore an SVM root volume. I am sure support escalations has and maybe I have been lucky.. but the goal is follow all best practices so we use LS Mirrors. For the encryption issue I ran into when using make-vsroot, the bug with make-vsroot not updating junction-paths to new SVM root, the two step procedure, etc... LS Mirrors just make the most sense and match the docs now which only discuss LS in the latest update.

[TMADOCTHOMAS]

@scottgelb thank you, this is an immensely helpful reply! Your list of reasons for sticking with the LS mirror approach make a lot of sense and I believe I will do the same.

Unfortunately, the Veeam workflow needs that command in the MIDDLE of their process (after creating the clone but before mounting it) and they don't have a mechanism for inserting a script at a particular point. I've submitted a request for enhancement, but it might not get much traction as I'm apparently the only one to report this issue :(. I tend to think it's because perhaps some NetApp users that use Veeam don't follow the best practice of the root volume protection, OR maybe they just haven't had to do a restore yet!

+1 on wishing this process were internal to NetApp OS processes and we didn't need to configure it! That would be great.

[scottgelb]

I have a brute force thought 🙂 It should work but has a small window of no mirrors... at the beginning of the script, tear down and destroy the LS mirror, and at the end of the process, re-create the LS mirror. So pre and post scripts can handle this..

[TMADOCTHOMAS]

Hmmm, intriguing @scottgelb ! Nice idea. Unfortunately the problem is I don't see any scripting options in the Veeam Guest File Restore wizard which is the wizard in question. Our whole reason for wanting to use Veeam is to provide a user-friendly restore interface to non-tech people.

[scottgelb]

One other thought... thinking about this a bit... don't do LS mirrors and break best practice... what is the worst case? You lose access until you "vol make-vsroot" on a new root volume then manually mount the junction-paths... I can't officially recommend a non-best practice like that but in this case more brute force may be the best method. Just be prepared to have to reconfigure SVM root permissions and all data volume junctions.

[TMADOCTHOMAS]

Yeah @scottgelb it's your last sentence that concerns me. It could be done but I don't like the idea of a time consuming process when I could have things back up quickly.

Incidentally, we've decided to punt and just do additional backups with Veeam, in addition to the NetApp backups. Just for a handful of key VMs. It's 'double-dipping' on space, but it's not a lot of space and won't kill anything. Not my preferred approach, but it will work.