Posts by SPGoetze

Mmm, yes. 11-nines data durability? Mmmm, that sounds good. Except it's virtually meaningless

Re: "Checksumming is another"

With checksums you can find different types of "silent" data corruption, like

- bit rot

- lost writes

- torn writes

- misdirected writes

Torn/Misdirected writes are more of a spinning disk thing, the rest could theoretically also appear in Solid-State devices.

When you determine, that the checksum doesn't fit the data (either when you access/read the data, or on a periodic schedule), you'll reconstruct the correct data from parity/erasure code/mirror or whatever your protection scheme might be, therefore "protecting the data from "silent" corruption (not failed drives) and increasing durability...

Hope that helps.

(I teach storage...)

Re: smoke and mirrors

We're talking DURABILITY here, not AVAILABILITY!

NFSaaS becomes ‘Azure NetApp Files’ as ONTAP-on-Azure debuts

Details about Cloud Volumes (not just on Azure) on Cloud Field Day...

http://techfieldday.com/appearance/netapp-presents-at-cloud-field-day-3/

Very informative presentation and lots of good questions from the delegates...

PSA: Pure has a PSO. That is, it's getting into container orchestration

Trident, anyone?

"We can immediately see what a neat idea it would be if other vendors provided it for their arrays."

Like NetApp has been doing for a while with the Trident project?

https://netapp.io/2017/02/13/trident-part-i-an-introduction/

Get it on GitHub...

Go forth and break it: Google pushes NASty Cloud Filestore to beta

Re: Azure "geographically redundant storage with 16 nines availability"

The Reg got it wrong, see below...

Re: Azure "geographically redundant storage with 16 nines availability"

They didn't claim that, the Reg got it wrong...

Durability is not availability!

Come on, Register! Read more carefully next time, please!

The "ridiculously" high numbers refer to DURABILITY, not availability (i.e. the probability, that the data gets LOST, not the probability that you temporarily can't access it). Quite attainable with modern storage systems... Guaranteed AVAILABILITY, according to the links you provided, is 3-4 nines, which is in line with what you would expect from a cloud service...

AI, AI, Pure: Nvidia cooks deep learning GPU server chips with NetApp

Not by much?

"It appears from these charts, at least, that NetApp Nvidia RA performs better than than AIRI but, to our surprise, not by much, given the NetApp/Nvidia DL system's higher bandwidth and lower latency – 25GB/sec read bandwidth and sub 500μsec – compared to the Pure AIRI system – 17GB/sec and sub-3ms"

From the *numbers* I see, it's ~220-280% performance. Maybe if you would scale the graphs the same, it would not "surprise" you so much... And from the looks of it, it's probably NetApp's latency advantage and we didn't reach bandwidth/throughput saturation yet (in these configurations).

We three kings of Dell EMC are; bigging up storage we traverse AFA

Re: The problem is implementation

First off, they bought Spinnaker in 2003 and 2004 or 2005 came out with ONTAP GX. IIRC around 2008/2009 they were the first to shatter the 1 Million IOPS Mark in the SpecNFS benchmark with a 24 node ONTAP GX system (which, according to reports at that time, was not a lab queen, but deployed just like that at multiple customers). I really don't know, where you get your 14 years from...

Second, it really depends on your definition of scale-out. It's not a shared nothing system like Solidfire, true. But if you can nondisruptively grow capacity and performance, e.g. using FlexGroups up to 20+ PetaBytes and 400+ billion files in a single namespace, by adding controller pairs, that's scale-out to me. In the end it's not about semantics, but about customer outcomes. And again, NetApp has a history of doing things differently (I remember "that's not a real SAN, they have a file layout underneath" from ~2009).

(Not a NetApp employee, I just teach storage for a long time...)

Flash-based and Dell-free: NetApp trots out SolidFire FlexPod

Some typos:

It's "Element OS" (twice)

It's the "SF9608" (in the bulleted list)

It's "scale-out", not scale-up

Rushing to meet a deadline? ;-)

Dell EMC canning XtremIO file services project

Hmmm, somehow I'm missing some products in the Flash Array Chart:

Where's the NetApp AFF systems? They've been around since June 2014... Supposedly they contribute the most to NetApp's Flash run rate of about $1.4 Billion (earnings call Feb-17). The A-Series is just a new name to the AFF...

Where's the NetApp EF systems? I don't know for sure, but I would have estimated them to be above SolidFire...

Anyway, adding the NetApp systems leaves me way below $1.4 Bio. Something's amiss...

Can NetApp's 4KB block writes really hold more data?

Re: Looking at the

Why recompress, if you read? Just throw away what you don't need...

Also keep in mind, that the in-memory cache will be compacted too, leading to "cache amplification", thereby *reducing* backend I/O for reads. Especially if "the I/O is concentrating on specific locations"!

Writes on the other hand might get a little more complicated, slightly mitigated by the fact, that WAFL always writes to new (4KB) blocks. (No read-rebuild-write, but more tricky garbage collection, I imagine)

Sebastian

(Disclaimer: I teach storage, mostly NetApp, but not affiliated with them)

BOFH: Thermo-electric funeral

Re: as if owning IT antiquity was one of those positive character traits

TI 59, IIRC...

NetApp adds in-line dedupe to all-flash FAS arrays

Re: Dedupe

Just FYI, we have 84% dedupe rate on our NFS datastores.

>14TB logical stored on ~3.5TB physical storage.

Dedupe is very much alive with us...

They were the first to offer dedupe... also for a long time the only ones to offer it for primary storage.

Who cares, if it wasn't inline!

That's only important if you want to reduce write amplification on flash systems.

And they did use 'always on deduplication' before, if you check the relevant Tech Reports (e.g. about Horizon View on a AFF system). Yes, there was some more write amplification, but again, who cares, since it was covered by the NetApp warranty anyway (and they didn't yet have a single SSD fail because of aging either).

Re: Dedupe

What you'd usually do on a NetApp system is, leave dedupe on, keep your snapshots, and *snapmirror* that to a different physical site. That way you have another physical set of copies of your data, not on the same spindles, but in another location, where you'd also be protected against site disasters (e.g. prolonged power outages, floods, fire, ...)

NetApp's running with the big dogs: All-flash FlashRay hits the street

Latecomer?

I wonder why NetApp is often considered a 'latecomer'...

The PAM card (16GB DRAM based Read Cache in a PCI slot) debuted in 2008 (ONTAP 7.3)

Flash Cache (called "PAM II" back then), which was NAND Flash, came in 2009. (ONTAP 7.3.2)

SSDs as disks were supported since ONTAP 8.0.1 in 2010. I've had students in my class who were happily running "All-Flash FAS" back then already. (SSDs for the root aggregate were supported later that year)

Not much had to change for Data ONTAP to support SSDs in an efficient way, since WAFL had handled disks just like SSDs already since 1992: delayed coagulated writes, spreading writes over the whole system (the proverbial "Write Anywhere File Layout", WAFL), delayed garbage collection, background File Layout Optimization ('reallocate'), and so on... Now finally other storage systems start doing the same things as a side-effect of adapting their systems to SSDs.

It's just that Marketing was late to the show and coined the term AFF (All-Flash FAS) fairly recently.

Same story with the EF-Series, by the way. Customers had been ordering E-Series systems with only SSDs already for a while, before the marketeers came up with the "EF" moniker.

By now NetApp has shipped more than 111PB of Flash.

Doesn't look like a Latecomer/Newcomer to me.

To me FlashRay is simply the new 'future-proof' OS-base, for when spinning disk is fading away.

It doesn't seem to me, that NetApp is under a lot of pressure to ship something 'flashy', since the available offerings (EF-Series for raw performance with storage management by the application, AFF for integration in existing NetApp FAS environments and rich on-box management features) are already covering a very broad base. The limited FlashRay release now I see more as a preview of things to come for selected stakeholders. I actually prefer the 'It's ready when it's ready' approach...

my 2c

Sebastian

(disclosure: I'm a NetApp Certified Instructor, but I work for an independent Technical Training Company, not for NetApp)

NetApp gives its FAS range a 4 MILLION IOPS dose of spit'n'polish

Re: Software

Well, *Data ONTAP* offers only RAID-DP (and RAID 4, and RAID 0 (V-Series), and all of them mirrored, if you'd like). The 2% performance penalty (vs. buffered RAID-4) should be less than one additional disk...

If you want performance with less Data Management Overhead, compare with the NetApp E-Series. It offers a variety of RAID schemes, plus 'Dynamic Disk Pools' (RAID-6 8+2 disk slices) which dramatically reduce rebuild time and impact.

Or get a hybrid ONTAP config (FlashCache / FlashPool). I haven't seen a too-many-spindles for performance NetApp config in a long time...

Re: Software

Hmmm, seing that RAID-DP was introduced with ONTAP 6.5 a good 10 years ago and only became the default in ONTAP 7.3 (2009) I can't quite follow your reasoning.

I DO follow the reasoning, that being protected while rebuilding a disk (something that RAID 4/5/10 doesn't provide) with only <2% performance penalty (which you probably won't notice) is something you should do by default.

Scalability, the way I understand it, was provided with the advent of 64-Bit Aggregates in ONTAP 8.x, especially 8.1+.

Re: 4 Mio IOPS probably not too far off the mark...

I'm fairly sure they arrived at the 4 Mio IOPS number by taking the old 24*6240 SpecNFS results (https://www.spec.org/sfs2008/results/res2011q4/sfs2008-20111003-00198.html) and factoring in the increase in controller performance.

The old result had 3 shelves of SAS disks per controller, so there's no unrealistic expensive RAID 10 SSD config required, like with other vendors results. Also 23 of 24 accesses were 'indirect', meaning that they had to go through the 'cluster interconnect'. pNFS would have improved the results quite a bit, I'm sure.

The old series of benchmarks (4-node, 8-node, .. 20-node, 24-node) also showed linear scaling, so unless you'd saturate the cluster interconnect - which you can calculate easily - the 4 Mio IOPS number should be realistic for a fairly small sized (per controller) configuration. Real life configs (e.g. SuperMUC https://www.lrz.de/services/compute/supermuc/systemdescription/ ) will probably always use less nodes and more spindles per node.

Storage rage: Like getting a nice steak and being told to only eat 80% of it

Re: Very odd article...

The analogy with the storage unit fits well:

- If you're not constantly changing what's in there, you'll be fine with a unit that fits barely.

- But if you're constantly bringing in new stuff and try to exchange it against stuff that's all the way in the back, you'll wish you had paid for a bigger unit...

Is Object storage really appropriate for 100+ PB stores?

800 PB...

The biggest StorageGrid installation I've heard about is 800 PB on 3 continents. I forgot how many sites, but it was quite a few... so apparently some people DO put more than 100 PB in one namespace.

Chatter foreshadows major NetApp ONTAP refresh

Sloppy research...

"ONTAP 8.1 could unify the separate 7G and 8.01 strands of ONTAP, and position NetApp to provide more scale-out features to cope with larger data sets."

Now really, Who would want to unify those two??

8.0.x comes in two flavours: 7-Mode (ex-7G) and Cluster-Mode (ex-GX). Same code-base, different environment variables to tell the system in which mode to start.

More Scale-Out? Cluster-Mode already gives you up to 28 PB (on 24 nodes) in a single namespace. I'm teaching NetApp and talked to a student 2 weeks ago, who will be setting up a new 5PB system in the coming weeks...

(8.0.2RC1 already supports 3TB drives which will proportionally increase the above numbers...)

"We might expect more use to be made of flash memory devices, something around data storage efficiency, and clustering improvements."

More flash? The 6280A already supports 8TB PCI-Flash. With 8.0.2 (RC already publicly available) this will increase to 16TB... SSD shelfs are supported for about a year already.

Storage Efficiency? Compression is available as of 8.0.1 (7-Mode). You can even combine it with deduplication where it makes sense.

No, 8.1 is simply the convergence of 8.0.x 7-Mode and Cluster-Mode with added benefits.

NFS smackdown: NetApp knocks EMC out

Didn't the benchmarks prove otherwise??

"Your cache becomes a bottleneck, because it isn't large enough to handle the competing storage access demands.

Better to build the whole array out of Flash, and (if necessary) use on-controller RAM for cache, methinks, than to use a flash cache with mechanicals hanging off the tail-end. "

The FlashCache on the NetApp system was only a fraction of the dataset used in the benchmark (~4.5% of the dataset, ~1.2% of the exported capacity), yet it had 172% more IOPs, delivering them with ~half the latency (198% faster). The system also had 488% the exported capacity at a fraction of the cost of the all-SSD system...

As opposed to the 'large sequential' workload, where predictive cache algorithms can really shine, I see only one use case for SSDs:

Unpredictably random read workloads, where the whole dataset fits into the SSD-provided space. I know one such application, NetApps with SSD-shelfs were deployed after extensively testing multiple vendor's solutions.

EMC buys Isilon for $2.25bn

Cluster-Mode

"that their systems are different in kind from mainstream clustered filers such as NetApp's FAS series. NetApp would disagree of course."

I guess NetApp would agree, actually. And sell you an ONTAP8 Cluster-Mode System. 24 nodes, 28PB capacity. If you need more, there's always NetApp's StorageGRID...

NetApp adds SSDs and 2.5-inch drives

Automatic Sub-volume level movement??? Non-sensical on NetApp!

"The hints are strong that Data Motion is going to get automated and, hopefully, there will be sub-volume level movement to provide more efficient control of hot data placement, as NetApp's competitors do."

Now that makes no sense whatsoever on a NetApp. If only part of a volume is 'hot', already the second read-access to it would find it in (Flash-)Cache. Writes are always acknowledged to clients as soon as they're safe in NVMEM, so no speeding up necessary there. They're also automatically in Cache, so the next read would already find them there.

98% of use cases are transparently accelerated by Flash-Cache. You can put up to 8TB in a NetApp HA pair...

The other 2% (I know one case) can actually benefit from SSDs. But then it's a *whole* dataset that needs to be fast *all* the time, at the *first* access (because there will probably be no second any time soon) and you wouldn't want the risk of having to warm up the cache after a controller failover. That dataset would go to SSD as a whole, not 'sub-volume'...

I can see lot's of use-cases for automatic DataMotion, but (sub-volume) 'FAST' isn't one of them.

Disclosure: I'm a NCI, a technical Instructor, teaching people (among other things) how to use NetApp controllers. I like their technology, but I'm not an employee...

3PAR zeroes in on wasted space

Deduplicate Zeros & Most Mature ?

I'd agree with 'most mature *hardware-based* thin provisioning'.

But if you compare the features described in the article with what NetApp offers in their boxes, it's a fraction only. Like

- specific space guarantees for volumes, LUNs, files

- volume autogrow

- snapshot (operational backup) autodelete

- deduplicating ANY 4K blocks of data (not just zeroes)

With all these safety measures built in, it's perfectly safe to use Thin Provisioning, provided you do a little monitoring, too.

I agree with Barry, Software is a lot more flexible, and these days pretty fast...

Scale-out SVC on the way from IBM?

FCoE is an approved standard since June 3, 2009

You said: There are standardisation efforts with FCoE and data centre Ethernet afoot.

'On Wednesday June 3, 2009, the FC-BB-5 working group of T11 completed the development of the draft standard and unanimously approved it as the final standard. '

See also: http://www.fibrechannel.org/component/content/article/3-news/158-fcoe-standard-alert-fcoe-as-a-standard-is-official-as-stated-by-the-t11-technical-committee