toasters April 2021

toasters@lists.teaparty.net

18 participants
13 discussions

2node system, migration to a new box?
by Sami Kapanen 21 May '21

21 May '21

We have 2node FAS2520 (no switches). How to migrate SVMs to a new cluster? Want to preserve CIFS server names and IP addresses. Last time we used 7MTT to do the migrations.. is there similar tool for cluster mode migrations? br, sk

4 5

Re:
by André M. Clark 01 May '21

01 May '21

One thing that I have always thought about with SVM root vol protection is, if it is an operational recommendation, why aren’t they automatically created in a System Manager workflow when a NAS SVM is created? Things to make you say, Hmmmmmmmn From: Scott M Gelb via Toasters <toasters(a)teaparty.net> <toasters(a)teaparty.net> Reply: Scott M Gelb <scottgelb(a)yahoo.com> <scottgelb(a)yahoo.com> Date: April 28, 2021 at 16:46:47 To: Parisi, Justin <justin.parisi(a)netapp.com> <justin.parisi(a)netapp.com>, John Stoffel <john(a)stoffel.org> <john(a)stoffel.org> Cc: toasters(a)teaparty.net <toasters(a)teaparty.net> <toasters(a)teaparty.net> Subject: I have used both DP and LS over the years and am back to using LS more often for reasons Justin wrote, and also for an NAE/NVE workaround where DP make-vsroot had some hoops to jump through to re-create the mirrors after a failover test. LS mirror promote and recreate after had no issues with NAE/NVE in my testing. In all the years doing this, I've never had to recover svm root, but to follow best practices for NAS, still implement them. I don't create mirrors on all nodes and use 1-2 copies depending on cluster size. An interesting test in mirror activation, is that the mirror picks up the existing SVM junctions regardless of the state of SVM root mirror. For example: 1) An SVM has 4 junction paths 2) SVM root mirror LS or DP to protect SVM root 3) unmount 3 of the junction paths leaving 1 junction path 4) failover to the root mirror (promote LS or break/make-vsroot DP) 5) SVM root running on the failed over volume has the 1 junction path, not the 4 that existed at the time of the mirror... there was no real failure, and the procedure with the SVM running keeps the current state. If a real disaster, I would expect recovery to what was in the mirror, but have never had to recover svm root. An RFE on my wish list is to have the SVM root virtualized in the RDB, then we don't need to manage, replicate or ever move SVM root. I know this isn't an easy task and would use mroot/vol0, and cause more cluster traffic, but still would welcome seeing a change to do this if feasible. Not a show stopper or requirement, nor high priority. On Wednesday, April 28, 2021, 11:24:12 AM PDT, John Stoffel < john(a)stoffel.org> wrote: Justin> Another pretty major difference between LS and DP methods; Justin> DP method requires manual intervention when a failover/restore is needed. This is fine in my case, because I'm really trying to protect against a shipping failure, though it's tempting to do more to protect against root volume failures as well. Though I've honestly never had one, nor had a netapp fail so badly in 22+ years of using them that I lost data from hardware failures. Closest I came was on a F740 (I think) using the DEC StorageWorks canisters and shelves. I had a two disk failure in an aggregate. One disk you could hear scrapping the heads on the platter, the other was a controller board failure. Since I had nothing to lose, I took the good controller board off the head crash drive and put it onto the other disk. System came up and found the data and started rebuilding. Whew! Raid-DP is a good thing today for sure. Justin> LS Mirrors are running in parallel and incoming reads/access Justin> requests (other than NFSv4) hit the LS mirrors rather than the Justin> source volume, so if one fails, you don’t have to do anything Justin> right away; you’d just need to resolve the issue at some Justin> point, but no interruption to service. That's a decent reason to use them. Justin> LS mirrors can also have a schedule to run to avoid needing to Justin> update them regularly. And, if you need to write to the SVM Justin> root for some reason, you’d need to access the .admin path in Justin> the vsroot; LS mirrors are readonly (like DP mirrors). The default for 9.3 seems to be 1 hour, but I bumped it to every 5 minutes, because I have Netbackup backups which use snapshots and 'vol clone ...' to mount Oracle volumes for backups. I had to hack my backuppolicy.sh script to put in a 'sleep 305' to make it work properly. Trying to make it work generically with 'snapmirror update-ls-set <vserver>:<source>' wasn't working for some reason, so the quick hack of a sleep got me working. But I am thinking of dropping the LS mirrors and just going with DP mirrors of all my rootvols instead, just because of this issue. But let's do a survey, how many people on here are using LS mirrors of your rootvols on your clusters? I certainly wasn't across multiple clusters. Jhn _______________________________________________ Toasters mailing list Toasters(a)teaparty.net https://www.teaparty.net/mailman/listinfo/toasters _______________________________________________ Toasters mailing list Toasters(a)teaparty.net https://www.teaparty.net/mailman/listinfo/toasters

5 5

is there any way to change the number of constituent volumes in a flexgroup?
by Rue, Randy 29 Apr '21

29 Apr '21

Hi All, After some time playing with flexgroups it appears they're pretty much just a RAID0 stripe of flexvols, or something like a linux LVM construct. I keep stumbling over the fact that if I create a FG from the webUI it spans my two data aggrs and creates two constituent volumes, but if I use the CLI the default "span count" is four and I get 8 CV's. 8 would be better as we expect to have a third aggr fairly soon if not more. Is there any way to change the number of CV's in an existing FG? If this really is essentially a RAID0, I can see why not. I've tried a flexclone, but when I split it off I get an identical FG. If I try to snapmirror the FG from the webUI it doesn't allow me to connect to an existing FG or to set any parameters on the created volume. In this case I've already created and loaded a 4TB FG that I now see only has two CV's. I could destroy it and start again but it seems probable I'll face this situation some day that I don't want to have to copy over. Thanks in advance, Randy in Seattle

3 2

Root volume LS mirror best practices?
by John Stoffel 28 Apr '21

28 Apr '21

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

5 5

Relocating a MetroCluster node?
by Walfherder 27 Apr '21

27 Apr '21

Hi All, I have a customer with a fabric MetroCluster. It consists of two FAS8200 Systems, each with dual controllers plus associated ATTO 7500N bridges and Brocade 6510 switches. These are currently all installed and in production in a single location. (All running 9.7P4) They plan to move one node of the MetroCluster to a new DC around 40 Kilometres away i.e. one of the 8200 systems and its associated shelves, bridges and switches will be relocated. As I understand it, the plan is to keep one MetroCluster node running while the other is being moved. Once the relocated node is up and running, then the data will be re-synced. I haven't been involved in relocating half of a MetroCluster before and naturally I am wondering what there is to watch out for. For example: - Is there a documented procedure for doing something like this? (I mean for example something similar to that which the Upgrade Advisor might generate) - How best to split / stop / start / reconnect the MetroCluster nodes? - What's the best way to manage the (re-)distribution of the SVMs (if this is manually required / necessary)? - The aggregates of the remaining, running, node will need to store more data during the move, right? - What's the best way to assess how much space will be required? - Should the aggregate % reserves also be increased during the move? - Anything to stop or to avoid prior to / during the move? - Any other advice gratefully received :-) Thanks in advance! Yours, Waflherder

2 2

AFF-A220 9.8P1 default aggregates and root volumes
by Rue, Randy 26 Apr '21

26 Apr '21

Hello, We're setting up a new and relatively small SSD NAS and it's arrived configured for two equally sized tiers with each node and its root aggr/vol in each tier. Each tier is about 15TB in size before compression. We're hoping to avoid needing to manage two equally sized data aggrs and moving data volumes around to balance them. For one thing, our largest data volumes are larger than 15TB and snapmirror doesn't seem to want to let us set up a relationship to load the new volumes from our old cluster, even if the target has ample room after the guaranteed 3X compression. We're willing to lose the wasted space involved in creating one tier/partition/aggr/root volume with the minimum number of disks for raid-dp (3?) for one node if that will allow us to put the rest on the other set and have a single large container for our unstructured file volumes. We tried moving all volumes to one tier and deleting the other. But one node is still sitting on those disks. Our old cluster is at 9.1P6 and I'm clear that some basic concepts have changed with the introduction of partitions and whatnot. So bear with me if I'm asking n00b questions even after a few years running NetApp gear. * Is what I've proposed above reasonable? (one minimum aggr and one large one) Is it commonly done? Is it a good idea? * Can you point me to any "change notes" type doc that explains these new terms/objects to an otherwise experienced NetApp admin? * If the above is viable, what do I need to do to get there? For what it's worth, I've been noodling a bit with the "system node migrate-root" command (this new AFF is not in production yet) and got a warning that my target disks don't have a spare root partition (I specified some of the disks on the "old" aggr). That warning says I can find available disks with the command "storage disk partition show -owner-node-name redacted-a -container-type spare -is-root true" but the CLI then complains that partition is not a command (I'm at "advanced" privilege level). Is the given command correct? Hope to hear from you, Randy in Seattle

6 13

Disk Shelf support rail part number needed
by John Stoffel 22 Apr '21

22 Apr '21

Guys, I'm trying to mount a DS2246 disk shelf into a Netapp cabinet with a pair of FAS8060 heads. The shelf is coming from another Netapp cabinet and uses the regular support rails. But in the FAS8060 cabinet, the rear rails are mounted further back, and it looks like there is an extension bracket mounted on the rear post to support the support rail. I'm pretty sure my rails are as shown in this document: https://library.netapp.com/ecm/ecm_download_file/ECMP1139640 but I can't seem to find exactly what I need. Some digging leads me to think I might need X877B-R6 mounting kit. Or better yet, is it the X8783A-R6 with some sort of extension? I'm across the country from the system now, so I can't just go and look at it very easily. Any suggestions are appreciated. John

1 0

Snapshot policy disabled after clone creation
by Heino Walther 22 Apr '21

22 Apr '21

Hi there We have volumes that have snapshot policies (and snapvault relations). Every time a clone of the volume is created (thin provisioned), the snapshot policy is disabled for some odd reason. It then takes a few days for our monitoring system to pick up that something is wrong, we then enable the snapshot policy again, and it works again… The snaphot policy is SVM based (I think you are also able to do cluster wide snapshots policies?) But it’s quite annoying, and I was wondering if there were an option to stop this from happening? This is on ONTAP 9.7P7 but has been like this for several versions on ONTAP. /Heino

1 0

Rubrik - restores to NetApp -- Symlink Modtime not being restored
by John Adams 16 Apr '21

16 Apr '21

Hi All -- I have a question for others that are using Rubrik for backups.. I've noticed that when symlink's are restored.. they are restored with time/date of the restore.. not the time/date of the original.. For example: I moved test to test-hide and then restored test from Rubrik (overwrite original) . The restored Symlink has the time I did the restore.. not the original mod date. lrwxrwxrwx 1 uid gid 22 Apr 14 07:53 test-> /testfile lrwxrwxrwx 1 uid gid 22 Mar 29 2010 test-hide -> /testfile The backup was done with Netapp SnapDiff enabled. The NetApp is running 9.7P5. The Rubrik is running 5.3 Any others using Rubrik that see this? Thanks.

1 0

SnapDiff/Rubrik
by Steiner, Jeffrey 12 Apr '21

12 Apr '21

NDMP is a backup control protocol, but it's not a data format. Even ONTAP has multiple formats for NDMP backups. In the first release of NDMP, the backup was a near mirror of ufsdump, and it was pretty easy to restore an ONTAP backup to something like Solaris. You'd get some weird permissions, but it did work. The problem with ufsdump formats is the controller has to create the files and stream them off to the backup destination. About 10 years back, ONTAP added the ability to do NDMP backups using a snapmirror format. It was just the raw WAFL data, and it was WAY faster. It also meant that unless a system could real WAFL, there would be no way to use those backups. It was a nice option for full backups with a low chance of needing to be recovered, because recovery would requiring restoring the entire volume object that you backed up. Snapdiff allows a backup application to do incremental-forever backups. It could ask ONTAP to identify changed files from the previous backup and provide the list of files to be backed up to the backup app, which would be read from an NFS/SMB share. I didn't think NDMP was involved. Does the Rubrik documentation mention a NFS or SMB share path? If the ONTAP system went away someday, I would expect you could use a Cloud Volumes ONTAP instance in Azure or AWS to restore the data. There used to be some sort of limitation with NDMP and CVO, but I can't see why Snapdiff wouldn't work as usual on CVO. I'll ping a couple of guys... From: Toasters <toasters-bounces(a)teaparty.net> On Behalf Of Heino Walther Sent: Saturday, April 10, 2021 5:34 AM To: Brian Parent <bparent(a)ucsd.edu>; toasters(a)teaparty.net Subject: SV: NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe. As fas as I can remember snapdiff is using NDMP which should be a standard and open protocol, but NetApp, EMC and others have made their specific changes to their version of NDMP which basically make them not interchangeable. So I guess you will need a NetApp controller in order to restore your data. There is a slim chance that files can be restored to other NDMP devices (CIFS or NFS), but LUNs are required to be restored to a NDMP. You can either just keep a NetApp controller ready for this (with no service on it) or maybe just setup an ONTAP Select virtual instance in vSphere which you will be able to restore to, and it's not as expensive and a NetApp Hardware box. /Heino Fra: Toasters <toasters-bounces(a)teaparty.net<mailto:toasters-bounces@teaparty.net>> på vegne af Brian Parent via Toasters <toasters(a)teaparty.net<mailto:toasters@teaparty.net>> Dato: lørdag, 10. april 2021 kl. 02.12 Til: toasters(a)teaparty.net<mailto:toasters@teaparty.net> <toasters(a)teaparty.net<mailto:toasters@teaparty.net>> Emne: <no subject> _______________________________________________ Toasters mailing list Toasters(a)teaparty.net<mailto:Toasters@teaparty.net> https://www.teaparty.net/mailman/listinfo/toasters

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters April 2021