toasters

toasters@lists.teaparty.net

1 participants
13515 discussions

IOPS Planning for the Deswizzle Process?
by Philbert Rupkins 10 Feb '15

10 Feb '15

Hello Toasters, We've unfortunately had to reduce the frequency of our volume snapmirror updates in order to allow for our destination aggregate to deswizzle. We highly prefer hourly volume snapmirror updates but it turns our our source volumes are large enough and/or have enough snapshots that the deswizzle process never completes on the destination aggregate. Our volume snapmirror destination aggregate is a single tray of SATA. Prior to reducing the frequency of snapmirror updates, the SATA aggregate was running at 90-100% utilization 24x7 with little to no IO to the filer from active clients. Needless to say, serving data from said aggregate was VERY SLOW despite the light IO (<300 IOPS) required by the clients sourcing their primary data from the SATA aggregate. We've done what we can to reduce the impact of deswizzling. Namely, cutting down on snapshots and reducing the volume size. I understand reducing volume size doesnt reduce the maxfiles setting which believe ultimately impact the amount of deswizzling necessary on the destination. I'm still digging into other options we can try but reducing the frequency of snapmirror updates seems to have the most impact. How does one plan for IOPs or disk utilization resulting from the deswizzle process? If I recall correctly, during our planning sessions with NetApp, our Netapp SE never touched on IOPs or number of spindles required to handle deswizzling while serving data from the same aggregate. In fact, I think our aggregates were size purely based on the amount of IO generated from active clients (not active clients + deswizzle). Thanks, Phil

2 3

Re: IOPS Planning for the Deswizzle Process?
by Philbert Rupkins 10 Feb '15

10 Feb '15

Can you expand upon why QSM wouldn't be a good choice for a general DR use case? We currently do not use "vfiler dr" and have no immediate plans to use it in the future. On Thu, Feb 5, 2015 at 2:28 PM, Peter-Paul Witta <paul.witta(a)cubit.at> wrote: > Great! > Just keep in mind QSM might not be the best choice for DR or vfilerDR use > cases... > > kind regards, > Ing. Peter-Paul Witta > Chief Technology Officer www.CUBiT.at > Mobile +436644542287 > Office +4317189880-0 > > Am 05.02.2015 um 21:17 schrieb Philbert Rupkins <philbertrupkins(a)gmail.com > >: > > Just a quick update. We're generally a volume snapmirror shop. I think > I read somewhere that VSM is generally recommended in most cases. > > However, I also read that Qtree SnapMirror is not subject to the same > deswizzling process that runs on the destination when using VSM. My > understanding is this is because VSM is block based whereas QSM is not. > The SnapMirror TR goes through a fairly decent list of the differences > between VSM and QSM. Since QSM does not require deswizzling, I think > we are going to give QSM a shot for the volumes with many snapshots. > Sure, we'll need to dedupe the QSM destination and figure out how to manage > snapshots, but QSM sounds like something we need to consider given the high > disk utilization resulting from the deswizzle process. > > -Phil > > On Tue, Feb 3, 2015 at 10:44 AM, Philbert Rupkins < > philbertrupkins(a)gmail.com> wrote: > >> Paul, >> >> Thanks for this tip. I cant find much about the wafl.deswizzle.enable >> option on the support site. I did find a document that says "This is a >> diagnostic mode option that should only be used as part of an action plan >> under NetApp Global Support supervision." I guess I'll be giving them a >> call. >> >> Did you find this option mentioned in another document somewhere? >> Quarterly, we refresh an environment on the remote side which involves >> promoting a (volume) snapmirror replica to a primary copy of the data. >> I just want to make sure I am not going to shoot myself in the foot (from a >> performance perspective) with this option when we break a snapmirror >> replica and use the destination as a primary copy. >> >> Thanks, >> Phil >> >> On Tue, Jan 27, 2015 at 2:04 PM, Peter-Paul Witta <paul.witta(a)cubit.at> >> wrote: >> >>> if you do not plan to use the destination regularily tun the >>> deswziller off. >>> otherwise you'd deswizzle lots of snapshots you'll never use active on >>> the destination anyway... >>> >>> greets, >>> paul >>> >>> >>> Am 27.01.15 um 20:55 schrieb Philbert Rupkins: >>> >>> Hello Toasters, >>> >>> We've unfortunately had to reduce the frequency of our volume >>> snapmirror updates in order to allow for our destination aggregate to >>> deswizzle. We highly prefer hourly volume snapmirror updates but it turns >>> our our source volumes are large enough and/or have enough snapshots that >>> the deswizzle process never completes on the destination aggregate. Our >>> volume snapmirror destination aggregate is a single tray of SATA. Prior to >>> reducing the frequency of snapmirror updates, the SATA aggregate was >>> running at 90-100% utilization 24x7 with little to no IO to the filer from >>> active clients. Needless to say, serving data from said aggregate was >>> VERY SLOW despite the light IO (<300 IOPS) required by the clients sourcing >>> their primary data from the SATA aggregate. >>> >>> >>> We've done what we can to reduce the impact of deswizzling. Namely, >>> cutting down on snapshots and reducing the volume size. I understand >>> reducing volume size doesnt reduce the maxfiles setting which believe >>> ultimately impact the amount of deswizzling necessary on the destination. >>> I'm still digging into other options we can try but reducing the frequency >>> of snapmirror updates seems to have the most impact. >>> >>> How does one plan for IOPs or disk utilization resulting from the >>> deswizzle process? If I recall correctly, during our planning sessions >>> with NetApp, our Netapp SE never touched on IOPs or number of spindles >>> required to handle deswizzling while serving data from the same aggregate. >>> In fact, I think our aggregates were size purely based on the amount of >>> IO generated from active clients (not active clients + deswizzle). >>> >>> Thanks, >>> Phil >>> >>> >>> _______________________________________________ >>> Toasters mailing listToasters@teaparty.nethttp://www.teaparty.net/mailman/listinfo/toasters >>> >>> >>> >>> -- >>> kind regards, +43-664-4542287 >>> Ing. Peter-Paul Witta +43-1-7189880-0 >>> CTO/techn. Geschaeftsleitung www.CUBiT.at >>> >>> >> > _______________________________________________ > Toasters mailing list > Toasters(a)teaparty.net > http://www.teaparty.net/mailman/listinfo/toasters > >

2 1

"iscsi interface disable" Effect on Existing iSCSI Portals
by Philbert Rupkins 10 Feb '15

10 Feb '15

Hello Toasters, We have a client looking to limit iscsi services to a dedicated interface. It looks like, by default, ONTAP is running iSCSI portals on all interfaces in both the pfiler (vfiler0) and all vfilers. Is "iscsi interface disable" on vfiler0 (physical filer) the best way to get rid of all of the extraneous iscsi portals? Will running "iscsi interface disable" on the physical filer get rid of the iscsi portal(s) on the physical filers and vfilers? Not sure if I'll need to run a portal/tpgroup specific command or if "iscsi interface disable" will get rid of the portals. 8.1.3 7-Mode. Thanks, Phil

2 4

NT4 crypto ?
by Mark Flint 10 Feb '15

10 Feb '15

Anone seen this type of message in their AD logs:- The session setup from the computer NETAPP12B failed to authenticate. The name(s) of the account(s) referenced in the security database is NETAPP12B$. The following error occurred: The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you. And have an idea of why their appearing (all seems well with auth and CIFS ) and what I need to alter to make them stop, ‘cos my AD guy would;d like ti to atop, without him adding a new mail rule :) Thanks in advance, ~Mark

2 2

Re: nfsstat -l not in 8.1 ?
by Paul Letta 09 Feb '15

09 Feb '15

yep that was it.. thanks to you and the others that pointed that out. I knew it had to still be there.. Paul From: "Richard Payne" <richard.payne(a)amd.com> To: "Paul Letta" <letta(a)jlab.org>, "toasters" <toasters(a)teaparty.net> Sent: Monday, February 9, 2015 10:51:41 AM Subject: RE: nfsstat -l not in 8.1 ? You have multistore enabled/licensed. Instead run: vfiler run vfiler0 nfsstat –l --rdp From: toasters-bounces(a)teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Paul Letta Sent: Monday, February 09, 2015 10:48 AM To: toasters Subject: nfsstat -l not in 8.1 ? What happened to "nfsstat -l" on 8.1 ? I just tried to do this for the first time in a while.. "nfsstat -l" works fine on our 7.x and 8.2 filers.. Was it removed in 8.1..? I tried it with advanced commands turned on as well. I'm typing nfsstat dash ell... thanks, Paul xx> version NetApp Release 8.1.4P1 7-Mode: Tue Feb 11 23:23:31 PST 2014 xx> options nfs.per_client_stats.enable nfs.per_client_stats.enable on xx> nfsstat -l usage: nfsstat <interval> [ <count> ] usage: vfiler run <vfname> nfsstat -h [ -n [ <count> ] ] | [ [ <hostname or ip address> ] [ <interval> ] ] usage: vfiler run <vfname> nfsstat -l [ <count> ] usage: nfsstat -z usage: nfsstat -C usage: nfsstat [ -c ] [ -t ] xx> xx> priv set advanced Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel. xx*> xx*> nfsstat -l usage: nfsstat <interval> [ <count> ] usage: vfiler run <vfname> nfsstat -h [ -n [ <count> ] ] | [ [ <hostname or ip address> ] [ <interval> ] ] usage: vfiler run <vfname> nfsstat -l [ <count> ] usage: nfsstat -z usage: nfsstat -C usage: nfsstat [ -c ] [ -t ]

1 0

nfsstat -l not in 8.1 ?
by Paul Letta 09 Feb '15

09 Feb '15

What happened to "nfsstat -l" on 8.1 ? I just tried to do this for the first time in a while.. "nfsstat -l" works fine on our 7.x and 8.2 filers.. Was it removed in 8.1..? I tried it with advanced commands turned on as well. I'm typing nfsstat dash ell... thanks, Paul xx> version NetApp Release 8.1.4P1 7-Mode: Tue Feb 11 23:23:31 PST 2014 xx> options nfs.per_client_stats.enable nfs.per_client_stats.enable on xx> nfsstat -l usage: nfsstat <interval> [ <count> ] usage: vfiler run <vfname> nfsstat -h [ -n [ <count> ] ] | [ [ <hostname or ip address> ] [ <interval> ] ] usage: vfiler run <vfname> nfsstat -l [ <count> ] usage: nfsstat -z usage: nfsstat -C usage: nfsstat [ -c ] [ -t ] xx> xx> priv set advanced Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel. xx*> xx*> nfsstat -l usage: nfsstat <interval> [ <count> ] usage: vfiler run <vfname> nfsstat -h [ -n [ <count> ] ] | [ [ <hostname or ip address> ] [ <interval> ] ] usage: vfiler run <vfname> nfsstat -l [ <count> ] usage: nfsstat -z usage: nfsstat -C usage: nfsstat [ -c ] [ -t ]

3 2

Re: IOPS Planning for the Deswizzle Process?
by Philbert Rupkins 05 Feb '15

05 Feb '15

Paul, Thanks for this tip. I cant find much about the wafl.deswizzle.enable option on the support site. I did find a document that says "This is a diagnostic mode option that should only be used as part of an action plan under NetApp Global Support supervision." I guess I'll be giving them a call. Did you find this option mentioned in another document somewhere? Quarterly, we refresh an environment on the remote side which involves promoting a (volume) snapmirror replica to a primary copy of the data. I just want to make sure I am not going to shoot myself in the foot (from a performance perspective) with this option when we break a snapmirror replica and use the destination as a primary copy. Thanks, Phil On Tue, Jan 27, 2015 at 2:04 PM, Peter-Paul Witta <paul.witta(a)cubit.at> wrote: > if you do not plan to use the destination regularily tun the deswziller > off. > otherwise you'd deswizzle lots of snapshots you'll never use active on the > destination anyway... > > greets, > paul > > > Am 27.01.15 um 20:55 schrieb Philbert Rupkins: > > Hello Toasters, > > We've unfortunately had to reduce the frequency of our volume snapmirror > updates in order to allow for our destination aggregate to deswizzle. We > highly prefer hourly volume snapmirror updates but it turns our our source > volumes are large enough and/or have enough snapshots that the deswizzle > process never completes on the destination aggregate. Our volume > snapmirror destination aggregate is a single tray of SATA. Prior to > reducing the frequency of snapmirror updates, the SATA aggregate was > running at 90-100% utilization 24x7 with little to no IO to the filer from > active clients. Needless to say, serving data from said aggregate was > VERY SLOW despite the light IO (<300 IOPS) required by the clients sourcing > their primary data from the SATA aggregate. > > > We've done what we can to reduce the impact of deswizzling. Namely, > cutting down on snapshots and reducing the volume size. I understand > reducing volume size doesnt reduce the maxfiles setting which believe > ultimately impact the amount of deswizzling necessary on the destination. > I'm still digging into other options we can try but reducing the frequency > of snapmirror updates seems to have the most impact. > > How does one plan for IOPs or disk utilization resulting from the > deswizzle process? If I recall correctly, during our planning sessions > with NetApp, our Netapp SE never touched on IOPs or number of spindles > required to handle deswizzling while serving data from the same aggregate. > In fact, I think our aggregates were size purely based on the amount of > IO generated from active clients (not active clients + deswizzle). > > Thanks, > Phil > > > _______________________________________________ > Toasters mailing listToasters@teaparty.nethttp://www.teaparty.net/mailman/listinfo/toasters > > > > -- > kind regards, +43-664-4542287 > Ing. Peter-Paul Witta +43-1-7189880-0 > CTO/techn. Geschaeftsleitung www.CUBiT.at > >

1 1

snapshots schedules and snapmirror for DR
by Rhodes, Richard L. 05 Feb '15

05 Feb '15

Since our filers are used for a document management system, backups (snapshots/snapmirror) are controlled by a host script which coordinates CIFS shares and Oracle DB backups, and DR transfers. Now, I've setup a general CIFS share (ie: a junk drawer) which uses "snap sched" for hourly/daily/weekly snapshots and snapmirror.conf to schedule snapmirror to a DR site. Q) When the snapmirror is broken and the DR copy of the share is in use, will the snap sched kick in and start working automatically, or does something need done for the DR site for the snap sched to start working? Thanks Rick ----------------------------------------- The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.

3 2

RE: snapshots schedules and snapmirror for DR
by Schneider, Stefan 05 Feb '15

05 Feb '15

The snapshot schedule is part of the volume configuration so it will start working automatically on the DR site if the snapmirror is broken off. Regards, Stefan Von: toasters-bounces(a)teaparty.net<mailto:toasters-bounces@teaparty.net> [mailto:toasters-bounces@teaparty.net] Im Auftrag von Rhodes, Richard L. Gesendet: Donnerstag, 5. Februar 2015 15:15 An: toasters(a)teaparty.net<mailto:toasters@teaparty.net> Betreff: snapshots schedules and snapmirror for DR Since our filers are used for a document management system, backups (snapshots/snapmirror) are controlled by a host script which coordinates CIFS shares and Oracle DB backups, and DR transfers. Now, I’ve setup a general CIFS share (ie: a junk drawer) which uses “snap sched” for hourly/daily/weekly snapshots and snapmirror.conf to schedule snapmirror to a DR site. Q) When the snapmirror is broken and the DR copy of the share is in use, will the snap sched kick in and start working automatically, or does something need done for the DR site for the snap sched to start working? Thanks Rick ________________________________ ________________________________ The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.

1 0

RE: Mixing 10k and 15k in a DS4243
by RM 04 Feb '15

04 Feb '15

You’re right. CBC error. Computing Before Coffee. That said, is it generally kosher to mix speeds in any given shelf? RM From: Clark, André M. [mailto:Andre.Clark@redeight.com] Sent: Wednesday, February 4, 2015 11:34 To: RM; toasters(a)teaparty.net Subject: Re: Mixing 10k and 15k in a DS4243 DS424x only does 15K SAS, SSD and 7.2K SATA drives. The 10K drives are in the DS2246 shelf. From: RM Date: Wednesday, 04 February 2015 at 12:56 To: "toasters(a)teaparty.net<mailto:toasters@teaparty.net>" Subject: Mixing 10k and 15k in a DS4243 Is there a prohibition on mixing 10k and 15k SAS in the same shelf? NOT the same aggr, just the shelf. Thx, RM

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