toasters

toasters@lists.teaparty.net

4 participants
13526 discussions

CVO on Standard/SATA PD
by Jeff Mohler 06 Aug '22

06 Aug '22

Does anyone here have experience on a standard PD layer using CVO? If so, I am looking for -throughput- maximus, limitations, lessons learned, on per volume write workloads. We are in a mode where we believe we were told there are 100-200MB/sec write "edges" of throughput to CVO on standard PD storage...just we're not quite in shape here to test that yet ourselves. _________________________________ Jeff Mohler <jmohler(a)yahooinc.com> Sr. Storage Architect & Principal Yahoo Storage Engineering & Operations (831)454-6712 It puts the bundles in the buckets, or else it gets the hose again.

2 1

Re:
by André M. Clark 06 Aug '22

06 Aug '22

Check to see if your volumes are thin provisioned on the destination side. By default, they would not be thin provisioned. Regards, André M. Clark On August 5, 2022 at 11:03:13, Timothy Naple via Toasters ( toasters(a)teaparty.net) wrote: My first guess would be that you might somehow be retaining more snapshots on the destination, perhaps at the volume level? snap list for all the volumes is identical on source and destination? Does df -h on both sides show which volumes, if any, have a size discrepancy? Maybe a 2nd guess would be that the space guarantee settings are different on the destination volumes. ------------------------------ *From:* Toasters <toasters-bounces(a)teaparty.net> on behalf of Heino Walther <hw(a)beardmann.dk> *Sent:* Friday, August 5, 2022 7:31 AM *To:* toasters(a)teaparty.net <toasters(a)teaparty.net> *Subject:* Space issues on older NetApp... Hi there We have two systems that mirror eachothers volumes via snapmirror. We are talking 7mode ONTAP 8.1.4 The two systems have the same controller: FAS3240 They have the same disks and aggregate configuration (70TB aggregates) On the source side we use volumes that are thin-provisioned with LUNs that have space reservation enabled, the LUNs are mostly close to 16TB (which is max) All volumes are snapmirrored to volumes on the destination system with the same size and placed on the same aggregates that mirror the source aggregates in size… The aggregates on the source are all below 95% used. Yet.. we are now at the situation where a few destination aggregates are 100% full, while the source aggregates are still under 95% used… I have checked almost everything, like aggregate snapshot reserves etc.. but they should be the same… Can anyone explain why this can happen? We are of cause at a “deadlock” now.. I don’t think we can add anymore disks to the aggregates as they are max size… The only think I can think of is either delete a volume from the affected aggregates, and re-sync the volume and hope it doesn’t fill up again… Another way would be to add disks and build a new aggregate, and move some of the volumes… Is there something I have missed? 😊 /Heino _______________________________________________ Toasters mailing list Toasters(a)teaparty.net https://www.teaparty.net/mailman/listinfo/toasters

2 2

Space issues on older NetApp...
by Heino Walther 06 Aug '22

06 Aug '22

Hi there We have two systems that mirror eachothers volumes via snapmirror. We are talking 7mode ONTAP 8.1.4 The two systems have the same controller: FAS3240 They have the same disks and aggregate configuration (70TB aggregates) On the source side we use volumes that are thin-provisioned with LUNs that have space reservation enabled, the LUNs are mostly close to 16TB (which is max) All volumes are snapmirrored to volumes on the destination system with the same size and placed on the same aggregates that mirror the source aggregates in size… The aggregates on the source are all below 95% used. Yet.. we are now at the situation where a few destination aggregates are 100% full, while the source aggregates are still under 95% used… I have checked almost everything, like aggregate snapshot reserves etc.. but they should be the same… Can anyone explain why this can happen? We are of cause at a “deadlock” now.. I don’t think we can add anymore disks to the aggregates as they are max size… The only think I can think of is either delete a volume from the affected aggregates, and re-sync the volume and hope it doesn’t fill up again… Another way would be to add disks and build a new aggregate, and move some of the volumes… Is there something I have missed? 😊 /Heino

6 11

experience with standard PD layer using CVO?
by John Stoffel 06 Aug '22

06 Aug '22

>>>>> "Jeff" == Jeff Mohler via Toasters <toasters(a)teaparty.net> writes: Jeff> From: Jeff Mohler <jmohler(a)yahooinc.com> Jeff> To: Toasters <toasters(a)teaparty.net> Jeff> Date: Fri, 5 Aug 2022 10:15:13 -0700 Jeff> Subject: CVO on Standard/SATA PD Jeff> Does anyone here have experience on a standard PD layer using CVO? Jeff, I know you're deep in the weeds, but for those of us who aren't... can you spell out those acronyms please? PD = Purple Dinosaur? CVO = Cheery Victory Orange? *grin* Jeff> If so, I am looking for -throughput- maximus, limitations, Jeff> lessons learned, on per volume write workloads. Jeff> We are in a mode where we believe we were told there are Jeff> 100-200MB/sec write "edges" of throughput to CVO on standard PD Jeff> storage...just we're not quite in shape here to test that yet Jeff> ourselves. Yeah, you need to translate this section as well please. Or at least give a little more context so people have a hope of understanding. Or better yet, learning from your experiences! Cheers, John

4 4

Re: [E] Re: [EXTERNAL] experience with standard PD layer using CVO?
by Michael Bergman 06 Aug '22

06 Aug '22

There are such barriers w.r.t. (total) throughput from a VM to PD (and corresponding in AWS e.g.). But I very much doubt you'll hit those max throughput with CVO instances in any case. The problem would be 7.2K rpm back end: so very slow. No matter if you have a FAS appliance or a CVO, really. Then also CVO is a dog for WRITE pretty much in any case, always has been. Probably always will be, compared to real on-prem HW (FAS appliances). That's my $0.05 worth I *think* that what you're asking is in essence if anyone has been able to "max out" a theoretical 7.2K rpm based back in in a Hyperscalar Cloud with CVO. Can one do that with anything at all..? Some micro benchmark (fio, iozone)? I don't know. Never thought of that really, had no reason to ponder over it /M On 2022-08-05 23:10, Jeff Mohler via Toasters wrote: > Looking to see if any MB/sec on writes to sata physical disk backends have > been touched. > > Hearing that there may be (in some clouds) a write throughout barrier that > CVO may run into.

1 0

Re:
by Jeff Mohler 05 Aug '22

05 Aug '22

Whoops. PD=Persistent disk. Not physical. We don’t yet have vapor disks. :) On Fri, Aug 5, 2022 at 14:16 Jeff Mohler via Toasters <toasters(a)teaparty.net> wrote: > > > > ---------- Forwarded message ---------- > From: Jeff Mohler <jmohler(a)yahooinc.com> > To: Scott Miller <scott.miller(a)dreamworks.com> > Cc: John Stoffel <john(a)stoffel.org>, Toasters <toasters(a)teaparty.net> > Bcc: > Date: Fri, 5 Aug 2022 14:10:15 -0700 > Subject: Re: [E] Re: [EXTERNAL] experience with standard PD layer using > CVO? > Cloud volumes ontap > Physical disk > > :) > > Looking to see if any MB/sec on writes to sata physical disk backends have > been touched. > > Hearing that there may be (in some clouds) a write throughout barrier that > CVO may run into. > > On Fri, Aug 5, 2022 at 13:46 Scott Miller <scott.miller(a)dreamworks.com> > wrote: > >> >> CVO == Cloud Volumes Ontap, the software version of OnTap that you can >> run in the >> various CSP's (Cloud Service Providers) aka GCP, AWS, Azure >> >> https://cloud.netapp.com/ontap-cloud >> <https://urldefense.com/v3/__https://cloud.netapp.com/ontap-cloud__;!!Op6efl…> >> >> PD == Persistent Disk, what GCP (Google Compute Platform) calls its, uh, >> persistent disks. >> >> https://cloud.google.com/compute/docs/disks >> <https://urldefense.com/v3/__https://cloud.google.com/compute/docs/disks__;!…> >> >> And to answer Jeffs question, we've not done any CVO testing in GCP, so I >> can't >> answer the throughput questions. >> >> We have found that, in general, the VM Instance type that hosts the CVO >> instances matters, >> since the Instance type also determines networking connectivity. >> >> Disk type (in this case GCP PDs) matters, too; I'd test with Local SSD to >> see where >> that gets you. >> >> Lastly, Throughput is dependent on workload, which determines the IO >> pattern. >> Maybe create an FIO config that generates traffic close to what you >> expect, and >> use that to drive various CVO configurations. >> >> https://github.com/axboe/fio >> <https://urldefense.com/v3/__https://github.com/axboe/fio__;!!Op6eflyXZCqGR5…> >> >> -Skottie >> >> >> >> >> On Fri, Aug 5, 2022 at 1:26 PM John Stoffel <john(a)stoffel.org> wrote: >> >>> >>>>> "Jeff" == Jeff Mohler via Toasters <toasters(a)teaparty.net> writes: >>> >>> Jeff> From: Jeff Mohler <jmohler(a)yahooinc.com> >>> Jeff> To: Toasters <toasters(a)teaparty.net> >>> Jeff> Date: Fri, 5 Aug 2022 10:15:13 -0700 >>> Jeff> Subject: CVO on Standard/SATA PD >>> >>> Jeff> Does anyone here have experience on a standard PD layer using CVO? >>> >>> Jeff, I know you're deep in the weeds, but for those of us who >>> aren't... can you spell out those acronyms please? >>> >>> PD = Purple Dinosaur? >>> CVO = Cheery Victory Orange? >>> >>> *grin* >>> >>> >>> Jeff> If so, I am looking for -throughput- maximus, limitations, >>> Jeff> lessons learned, on per volume write workloads. >>> >>> Jeff> We are in a mode where we believe we were told there are >>> Jeff> 100-200MB/sec write "edges" of throughput to CVO on standard PD >>> Jeff> storage...just we're not quite in shape here to test that yet >>> Jeff> ourselves. >>> >>> Yeah, you need to translate this section as well please. Or at least >>> give a little more context so people have a hope of understanding. Or >>> better yet, learning from your experiences! >>> >>> Cheers, >>> John >>> >>> _______________________________________________ >>> Toasters mailing list >>> Toasters(a)teaparty.net >>> https://www.teaparty.net/mailman/listinfo/toasters >>> <https://urldefense.com/v3/__https://www.teaparty.net/mailman/listinfo/toast…> >>> >> -- > If it were me flying, Goose would be alive today. > > > > ---------- Forwarded message ---------- > From: Jeff Mohler via Toasters <toasters(a)teaparty.net> > To: Scott Miller <scott.miller(a)dreamworks.com> > Cc: Toasters <toasters(a)teaparty.net> > Bcc: > Date: Fri, 5 Aug 2022 22:10:33 +0100 > Subject: > _______________________________________________ > Toasters mailing list > Toasters(a)teaparty.net > > https://urldefense.com/v3/__https://www.teaparty.net/mailman/listinfo/toast… -- If it were me flying, Goose would be alive today.

1 0

Re:
by Stephen Stocke 24 Jun '22

24 Jun '22

Hi Steve. I've just checked our (non-Metro) clusters and I can confirm that most (probably all) the volumes that contain LUNs have nvfail set to 'on.' Certainly there are no 'non-LUN' volumes with nvfail set to on. Our transition 'through' 9.8 was directly from 9.7P13 to 9.9.1P7. We haven't had any LUNs go offline but we also haven't had any FO/GB events since the last ONTAP upgrade. HTH. Please update the list if you find out more. Kind regards Steve On Fri, 24 Jun 2022 at 14:52, Steve Kirk via Toasters <toasters(a)teaparty.net> wrote: > > > > ---------- Forwarded message ---------- > From: Steve Kirk <steve.kirk(a)sheffield.ac.uk> > To: toasters(a)teaparty.net > Cc: > Bcc: > Date: Fri, 24 Jun 2022 14:48:44 +0100 > Subject: NVFAIL - new behaviour or setting? > Hello toasters, > > I'm interested to know if anyone else has found recently that volumes > containing LUNs have gone into the 'NVFAIL' state during an ONTAP > upgrade or other event that causes an HA failover? > > It's not something we have ever specified on volume creation; > documentation suggests that it should be disabled by default however > all of our volumes containing LUNs appear to have NVFAIL enabled. My > *perception* this is a change since we upgraded to ONTAP 9.8. > > The documentation seems live under Metrocluster; our affected system > is not a Metrocluster: > > https://docs.netapp.com/us-en/ontap-metrocluster/manage/concept_monitoring_… > > It's also odd as the KB article says: > - This affords no extra protection for Storage Area Network (SAN) > hosts because SAN hosts reference LUNs by the LUN number assigned via > LUN maps and NOT by the LUN name. > - This protection was designed for file protocols, such as Network > File System (NFS) and Common Internet File System protocol (CIFS), > protect against corruption due to NVFAIL. > > Taken from here: > > https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/ONTA… > > So it also seems like either the setting or the documentation is the > wrong way round to me... > > Looking for feedback to see if anyone else has experienced this or if > there's something obvious we've missed before I raise a support call. > > Cheers, > Steve > > > > ---------- Forwarded message ---------- > From: Steve Kirk via Toasters <toasters(a)teaparty.net> > To: toasters(a)teaparty.net > Cc: > Bcc: > Date: Fri, 24 Jun 2022 14:49:13 +0100 > Subject: > _______________________________________________ > Toasters mailing list > Toasters(a)teaparty.net > https://www.teaparty.net/mailman/listinfo/toasters

2 1

NVFAIL - new behaviour or setting?
by Steve Kirk 24 Jun '22

24 Jun '22

Hello toasters, I'm interested to know if anyone else has found recently that volumes containing LUNs have gone into the 'NVFAIL' state during an ONTAP upgrade or other event that causes an HA failover? It's not something we have ever specified on volume creation; documentation suggests that it should be disabled by default however all of our volumes containing LUNs appear to have NVFAIL enabled. My *perception* this is a change since we upgraded to ONTAP 9.8. The documentation seems live under Metrocluster; our affected system is not a Metrocluster: https://docs.netapp.com/us-en/ontap-metrocluster/manage/concept_monitoring_… It's also odd as the KB article says: - This affords no extra protection for Storage Area Network (SAN) hosts because SAN hosts reference LUNs by the LUN number assigned via LUN maps and NOT by the LUN name. - This protection was designed for file protocols, such as Network File System (NFS) and Common Internet File System protocol (CIFS), protect against corruption due to NVFAIL. Taken from here: https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/ONTA… So it also seems like either the setting or the documentation is the wrong way round to me... Looking for feedback to see if anyone else has experienced this or if there's something obvious we've missed before I raise a support call. Cheers, Steve

1 0

(no subject)
by Iluhes 12 Mar '22

12 Mar '22

What is going with netapp and NAE encryption, none of the documenation make sense to me anymore.I see you should be able to move non ecrypted volume into NAE aggigate, but I cannotI get error, non-encrypted volumes are not supported in such aggegatesAll i want is to have NAE encryption, and volumes in the NAE aggr to be not encrypted so I can have aggr level dedup On Wednesday, March 9, 2022, 07:48:41 AM CST, Iluhes via Toasters <toasters(a)teaparty.net> wrote: Thanks, but before last step I will blow up space, right?At the moment that all volume are NVE I loose cross volume dedup and that what I cannot afford.How can I account how much space for any aggregate I will “loose” if there is no cross volume dedup On Mar 9, 2022, at 3:06 AM, Tim McCarthy <tmacmd(a)gmail.com> wrote: First, enable a key managerThen convert all data volumes to NVEvolume encrypt start …. After that, be sure any svm root volumes have been moved to the same aggregate. Then convert the aggregates without the svm to NAE -> aggregate modify -aggregate xx -encrypt Move the svm rootVol move start -volume svmroot -dest aggr-nae -encrypt-with-aggr-key true Encrypt the last aggregate Now convert all the volumes to nae:Vol move start -Vol xx -dest same-as-source -encrypt-with-aggr-key true If you do not do the last step, you will not have full NAE. There is a kb about this as well Get Outlook for iOSFrom: Toasters <toasters-bounces(a)teaparty.net> on behalf of Iluhes via Toasters <toasters(a)teaparty.net> Sent: Tuesday, March 8, 2022 11:20:29 PM To: Toasters <toasters(a)teaparty.net> Subject: _______________________________________________ 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

2 1

SVM-DR power or best practices guide?
by Scott Eno 10 Mar '22

10 Mar '22

Anyone know of a TR for SVM-DR best practices or power guide? The info in the ONTAP docs isn't very specific on technical details.

1 0

← Newer
1
2
3
4
5
6
7
8
...
1353
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