toasters

toasters@lists.teaparty.net

3 participants
13513 discussions

4 node cluster - only two nodes coming up
by John Stoffel 18 May '21

18 May '21

Hi all, We're in the middle of hell, where our 4-node FAS8060 cluster was shutdown cleanly for a move, but only one pair made it onto the truck to the new DC. Luckily I have all the volumes snapmirrored between the two pairs of nodes and their aggregates. But now I need to bring up the pair that made the trip, figure out which mirrors are source and which are destination on this pair, and then break the destination ones so I can promote them to read-write. This is not something I've practiced, and I wonder that if I have volume foo, mounted on /foo, and it's snapmirror is volume foo_sm, when I do the break, will it automatically mount to /foo? I guess I'll find out later tonight, and I can just unmount and remount. I think this is all good with just a simple 'snapmirror break ...' but then when we get the chance to rejoin the other two nodes into the cluster down the line, I would asusme I just have to (maybe) wipe the old nodes and rejoin them one at a time. Mostly because by that point I can't have the original source volumes come up and cause us to lose all the writes that have happened on the now writeable destination volumes. And of course there's the matter of getting epsilon back up and working on the two node cluster when I reboot it. Along with all the LIFs, etc. Not going to be a fun time. Not at all... And of course we're out of support with Netapp. Sigh... And who knows if the pair that came down won't lose some disks and end up losing one or more aggregates as well. Stressful times for sure. So I'm just venting here, but any suggestions or tricks would be helpful. And of course I'm not sure if the cluster switches made it down here yet. Never put your DC on the second floor if there isn't a second freight elevator. Or elevator in general. Sigh... John

5 9

Ndmpcopy times out...
by Heino Walther 18 May '21

18 May '21

4 10

Change local user SID
by Jeff Cleverley 11 May '21

11 May '21

Greetings, Is there a way to change the SID of a local NetApp user account? We have some instances where we archive old data from a primary cluster to a secondary cluster. We use local accounts instead of domain in many cases. We create the new local account on the secondary NetApp, but we now have a user account that shows as a SID and not as the actual user name. If we use SnapMirror, it tramples the top level permissions and we have to add the new local account permissions for the tree. It is obviously an inconvenience and not a deal breaker. Thanks, Jeff -- ** Please note my email address has changed to jeff.cleverley(a)broadcom.com Jeff Cleverley Factory Systems Engineer 4380 Ziegler Road Building 1, Dock 1 Fort Collins, Colorado 80525 970-288-4611 -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.

1 0

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

← Newer
1
...
7
8
9
10
11
12
13
...
1352
Older →

Jump to page:

2025

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