toasters

toasters@lists.teaparty.net

2 participants
13529 discussions

stuck creating an aggregate?
by Randy Rue 21 Feb '12

21 Feb '12

Provisioning a half dozen new aggregates on a new 3240 and while most of them completed within seconds, two are stuck at "initializing." Can't offline them, destroy them, or do anything at all to them without getting an error about the operation not being permitted on an aggregate that's still being created. One of them has been in this state for an hour now. Any advice? Anything I can do to shake them loose? Or should I just go take a nap and hope for the best?

3 2

upgrade a FAS980 with 10GB network cards possible?
by René Bormann 21 Feb '12

21 Feb '12

Hello Toasters, is it possible to use a 10GB network card in a FAS980 ? Cheers, René

4 4

vFiler migration with flex-clones fails - Volume is a clone and scanners have not completed on the parent volume: cannot execute operation
by Fletcher Cocquyt 20 Feb '12

20 Feb '12

It takes almost 6 hours to run the initial snap mirror sync for this vFiler migration, and its failed twice with Waiting for SnapMirror-Resync to complete on 'dbdev2, dbdev5, dbdev7' flex-clones… then SnapMirror Resync failed: Reason: SnapMirror error: Volume is a clone and scanners have not completed on the parent volume: cannot execute operation Src and dest are 3270 clusters running 8.1RC2 This is the last remaining migration blocking our long awaited shelf upgrade - and we have a case open with Netapp Anyone seen this one and worked around it? Thanks, Fletcher

2 4

FAS2240 and SSD
by Milazzo Giacomo 20 Feb '12

20 Feb '12

Hi all, expected for january 2012 there was the support to partially loaded DS4243 with 100 GB SSD units: 6 or 12. This was also reported in the "FAS2240 Technical questions" document by Chris Lueth. I'm trying to find some official doc that reports now this. Are these units really already supported on FAS2240? Regards Dott. Giacomo Milazzo [Descrizione: cid:image001.jpg@01C75422.0D316270] Technical Account Manager Sinergy SpA Filiale di Roma * 00198. viale Regina Margherita, 269 ' (+39) 3406001045 0644245272 7 (+39) 0226922048 * Giacomo.Milazzo(a)Sinergy.it

6 7

Storage VLAN ID assignment strategies?
by Ray Van Dolson 18 Feb '12

18 Feb '12

We have a range of VLAN IDs dedicated to storage related networks. Any of you out there find any value in reserving certain ranges for certain types of storage traffic (e.g. iSCSI, FCoE, NAS, etc all in different ranges)? Simplest is to just start at the lowest value and assign to the larger numbers, but maybe I'm missing some benefit for staying more organized here. Ray

2 1

deduplication, snapshots and performance questions
by Randy Rue 16 Feb '12

16 Feb '12

Hello All, We're troubleshooting some performance issues and trying to determine how deduplication might be might be muddying the waters on an already busy v3170 HA filer pair. There's also some likelihood that snapshots are involved. In a nutshell we have two Vfilers running on one node. One serves NFS datastores to our VMWare farm and all its volumes are de-duped. We recently migrated the other to the node, it's serving NFS to a wide variety of hosts and IO tends to be very heavy on metadata (get_attr and set_attr). We've found a pretty clear correlation between running de-dupes and performance complaints from customers of the other Vfiler. Whether we're running one de-dupe session or eight, CPU3 stays in the mid-high nineties. This is consistent with what NetApp has told us: that de-dupe processes live in the "Kahuna" domain that always ends up on one proc (in our case, the last of the four). They've also told us that de-dupe processes are heavily "niced" and shouldn't impact other processes, but after just having finished reading their 75 page PDF TR-3505 ("NetApp Deduplication for FAS and V-Series Deployment and Implementation Guide"), it's pretty clear the answer is a huge "it depends" and that de-dupe processes have a very real impact on performance. Especially if we're talking about a system that's otherwise heavily used, that is a higher model number, and that is using ATA drives (bingo on all three). Does anyone have any real-world experience with de-dupe processes impacting performance? Any suggestions for tuning? We've spent some time moving the schedules around but kept finding that efforts to spread them out were pretty fruitless: some volumes took much longer than others and eventually they started overlapping and stacking up. Right now we're running a script from another server that checks to see how many de-dupes are running and launches new ones as old ones complete, depending on what time it is. The end result is we run a constant loop over a list of fourteen VMWare datastore volumes with two de-dupes running on nights and weekends and none during the day. This means it takes about three days for that list to repeat; we used to run each volume every other day so we're watching the size numbers to make sure we don't hit any walls on the aggregates. Here's a tangent question. Does anyone know if, everything else being equal, two equal de-dupe jobs will complete faster if they're run sequentially or in parallel? If this process really is confined to a single proc and the work to be done is directly related to the ops available the blocks to be changed, it seems like should be a wash, but we haven't collected enough data to figure this out for ourselves (I'm afraid if we spend too much time running at only one process we'll have space problems). To add snapshots to the mix: we're running hourly snapshots on most or all of the volumes on both Vfilers. NetApp has told us this adds considerable performance load, most notably the work involved in releasing a snapshot as the oldest one rolls off the stack. They've said they can see instances in the logs where a snapshot begins before the previous one is finished. We're considering splitting the volumes into two groups and snapping them at alternate hours, so we get protection at two-hour granularity but each hour we're only processing half the volumes. However. Won't we then be processing twice as many changed blocks for each snapshot? Do we gain anything? We had this exact problem, for example, with a different storage vendor with a similar snapshot implementation. In that case their solution was actually to step up to snapshots every half hour. It ended up that processing smaller hunks of changed blocks more often solved our problem. Right now we're leaning toward trying a hybrid of these two approaches on our NetApp, splitting the volumes into two groups and running them at the top and bottom of the hour. We still get hourly snapshots on all volumes but only need to parse half as many in each pass. Anyway, I've rambled a lot and asked not many specific questions. What I'm hoping to hear is about: * Whether de-dupe processes scale linearly (do two jobs in parallel take the same total time as sequentially) * Anyone's experience tuning de-dupe processes and/or snapshots to minimize performance impact. Hope to hear from you, Randy

5 4

QFULL / vFiler
by Stuart Kendrick 15 Feb '12

15 Feb '12

How do I look for QFULLs on a vFiler? FAS3020 lun-stats -o -a /vol/vmware/vmware_db.lun (67 days, 5 hours, 14 minutes, 4 seconds) Read (kbytes) Write (kbytes) Read Ops Write Ops Other Ops QFulls Partner Ops Partner KBytes 0 0 0 0 0 0 0 0 V3170 lun-stats -o -a [empty output] --sk

1 0

Flash Cache questions: symmetrical cache mode required? Metadata mode only with a 512GB Flash Cache?
by Robert McDermott 11 Feb '12

11 Feb '12

Hello, We a V3170 cluster with a 512GB Flash Cache module installed in each controller. Each module is currently configured to cache normal data (default setting): flexscale.enable on flexscale.lopri_blocks off flexscale.normal_data_blocks on We have a vfiler running on one controller that does very little normal IO but has a very heavy metadata load due to poor application design. This vfiler has poor performance and its function is critical. We are thinking about switching to metadata only caching mode (flexscale.lopri_blocks off, flexscale.normal_data_blocks off) to improve its performance but have a couple of questions: The Flash Cache best practices guide has the following verbage about enabling metadata only mode: "Because of the much larger size of Flash Cache, this mode is more applicable to PAM I, the original 16GB DRAM–based Performance Acceleration Module, than Flash Cache." Does that mean that this setting doesn't apply (not recommended/supported) for Flash Cache? but is for PAM I? Is using metadata only mode a bad idea with a large flash cache module? If so why? The best practices guide also indicates that it's recommended to have a symmetrical number and size of modules between controllers in a cluster, but it doesn't say anything about symmetrical cache mode settings. Is it OK to have one controller's flash cache set to the normal data setting, but the others flash cache set to metadata only? During a failover the cache of the failed controller is essentially lost (doesn't follow it to the remaining controller) so it doesn't seem like it would matter as long as the cluster didn't stay in this failover state for a long period of time. What are your thoughts on this? Thanks in advance, -Robert

9 8

tracking aggr initialization progress ?
by Fletcher Cocquyt 11 Feb '12

11 Feb '12

Is there a way to track the progress (% complete?) for aggr creation/initialization? aggr status Aggr State Status Options aggr1 creating raid_dp, aggr raidsize=20, initializing snapshot_autodelete=off, 32-bit lost_write_protect=off thanks Fletcher

4 3

Re: The following prevents offline of volume: zapi snapshot list
by Fletcher Cocquyt 10 Feb '12

10 Feb '12

The snapshot process must have completed - I was able to offline by waiting a few minutes thanks Fletcher On Feb 10, 2012, at 2:31 PM, Parisi, Justin wrote: > Are you able to reboot the box? Because those will need to complete otherwise before it allows a vol offline. > > If you try to force the vol offline, it will hang. Reboot will clear this up and you should be able to offline the vols. > > From: toasters-bounces(a)teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Fletcher Cocquyt > Sent: Friday, February 10, 2012 4:57 PM > To: toasters(a)teaparty.net > Subject: The following prevents offline of volume: zapi snapshot list > > Hi > I'm attempting to offline all the volumes on this 64bit aggr so I can destroy and re-create as 32 bit (so 32->32 bit data motion is supported) > > I am encountering this error: > > The following prevents offline of volume vm2 > zapi snapshot list > zapi snapshot list > zapi snapshot list > > How do I clear it so I can proceed? > > thanks > > Fletcher > > > > > >

1 0

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