We have debated this point many times, but there are finally some stats being published about the actual usable capacity of Network Appliance disk once they have been right-sized. If accurate, and I have no way to verify this data, this could be a useful guide for those of you using NetApp gear.
I invite those of you who use NetApp, as well as readers from the vendor itself, to respond as to the veracity of these numbers.
{ 16 comments… read them below or add one }
I’m neither a user nor an employee of NetApp, but I do have an opinion.
The link starts out with the comment, “That 84 Terabytes of storage you thought you’d be getting? Think again.” Even if everything else the poster wrote is accurate (the guy obviously knows what he’s talking about), it starts out with the wrong premise. Who ever thought that they were going to get 84TB of usable storage with exactly 84TB of drive space? Is NetApp actually promoting that idea in their marketing collateral? If so, they’re liars. And anybody that believes it is stupid. I can’t be more blunt than that.
But anyone qualified to install a NetApp box should understand that RAID takes space and snapshots take space. Everyone knows that a RAID-5 on a fixed set of disks has less usable space than a RAID-0 on the same set of disks. But we’re willing to give up that space just for the ability to avoid having a single disk failure lose all of our data. And RAID-DP takes even more space than RAID-5. But there are further advantages, so folks live with it. The more protection against failure, the more overhead.
Same with snapshots – if you want to use them, then they take space. When the controller creates a virtual 1TB read/write snapshot, where does that snapshot live? Of course it takes disk space. Snapshots aren’t magic. They’re just a way of using storage. If someone doesn’t want to use 20% of their disk for snapshot, then they shouldn’t enable snapshot. It’s just like someone complaining that 20% of their disk is full of porn. OK, so stop downloading porn.
So does NetApp have evil in their heart? I don’t know, but I’m sure they have a little. I’m sure NetApp marketing literature is a little misleading to make their TB/$ look better. Everyone does it, but I guess it doesn’t make it right. And I’m pretty sure that every bit of storage they take is used for a purpose that somehow benefits the customer. Does anybody really think otherwise? (Damn, I’m sounding like a NetApp FanBoy.)
And should we blame people for not understand the details of RAID-DP or snapshot? Probably not. But should they understand that 84TB of disk space doesn’t equate with 84TB of storage? Heck yeah.
TT
I agree with you Tom. I just thought it would be useful to have a handy chart for usable capacity. I just wondered whether this guy was giving us ratios that were real.
You seem to think that he is.
Note that I would never write a rant about raw versus adjusted unless it was abundantly clear that someone was pulling my leg.
(You do sound a bit like a NetApp FanBoy, but I don’t think you want to leave Sunny Florida for Sunnyvale.)
A handy chart of usable capacity would be great.
For any Storage box.
Along with some other capacity related information.
Know where I can get one?
I’d be glad to help create one.
RE:”If someone doesn’t want to use 20% of their disk for snapshot, then they shouldn’t enable snapshot.”
Is this 20% before or after the commit?
That would be great if I could snapshot my 2 TB Storage into 400 GB and it was instantaneous or at least unnoticeable?
Of course, if I start snapshotting every 15 minutes from the “0″ creation time mark then the commit time is almost unnoticeable.
That’s 15 minutes on a very busy Storage device. And since snapshotting presents no overhead load to the NetApp box, according to them, I should set it up this way from the start.
Robert –
I don’t know how you could build such a chart. Every system is different and many systems provide multiple RAID levels. EMC CLARiiON has certain requirements for the first five HDDs, LSI/Engino/IBM/etc carve 512k off each disk, NetApp has RAID-DP or RAID-4 with WAFL overhead, etc. and the list can go on and on.
How about buyers specify the usable capacity they desire at specified RAID levels, the minimum number of hot spares and whether the capacity specified is GB or GiB and let the competing vendors build the proposals. If the winning vendor doesn’t provide the contracted capacity, hold their feet to fire, get what you paid for and then NEVER DO BUSINESS with that vendor again.
Tom said…
If someone doesn’t want to use 20% of their disk for snapshot, then they shouldn’t enable snapshot. It’s just like someone complaining that 20% of their disk is full of porn. OK, so stop downloading porn.
Hi Tom,
Its not like you can get back this space if you set your snap reserve to zero, the snap reserve is additional to the WAFL / parity / checksum / OnTap overhead (which is what this article is about).
The upto 20% you loose in each filer is a bugbear of mine – I gave my netapp reps a hard time about it yesterday as it happens
“The netapp overhead” I call it.
When I’m sizing filers I always make sure I reduce the total disk space by 20% compared to the physical space to make sure people aren’t disappointed.
eg 2 DS15′s full of 500G disks, 2 hot spares
2 x 13 x 500G = 13000G physically
2 x 13 x 500H x 0.8 = 10400G logically (using my rule)
Which doesn’t appear to be too wrong according to this article.
Alex
Hi, Alex. If the user is forced to reserve 20% of their disk for snapshot (whether they use it or not), then is snapshot at least included in the base price? I can “maybe” see forcing a feature like snapshot on their customer, but they sure better not charge extra for it! That would be very lame.
TT
My beef is more on the marketing side.
NetApp pushes out whitepapers and ads that state categorically that their environment uses less storage than other vendors. I haven’t found a credible basis for that claim. I don’t know if anyone else has, either.
Understand that the use of certain features (RAID-DP, snaps, etc.) take storage overhead, and most intelligent people willingly make that decision, but don’t go to the market and claim the precise opposite of what you deliver.
I thought the post on having vendors quote and deliver usable capacity, rather than raw, is spot on.
A newer wrinkle is having the vendor factor in “performance overhead”, (can’t fill them up, otherwise performance suffers) might be especially good advice for the filesystem-oriented storage devices in the market (NTAP, 3PAR, Isilon)
Cheers!
Maybe someone should read Dave Hitz’ Blog on why RAID-DP doesn’t waste disk space, but does raise data protection here: http://blogs.netapp.com/dave/TechTalk/?permalink=Why-Double-Protecting-RAID-RAID-DP-Doesnt-Waste-Extra-Disk-Space.html.
That is proof to a claim (at least as far as RAID-DP is concerned), whereas I have not seen any substantial independent proof for the claim you “can’t fill up ‘em up otherwise performance tanks…”. At least I don’t suffer from it.
“RE: Chuck Says: Robert – I don’t know how you could build such a chart.”
Having created these charts many times, and eventually automating the information gathering into the Electronic Inventory system (another interesting story), I can truthfully say the hard part is getting vendor cooperation in supplying information or contacts to ask for information.
Electronic Inventory is an inexpensive, extremely powerful friend for Configuration Management and Disaster Recovery. You can put the Configuration Information in a spreadsheet and make it dynamic. Today I would put the information in a Collaboration Wiki on a Collaboration server. It would still be dynamic. Very.
Having a good relationship with the Sales/Marketing people for a vendor is absolutely essential. Sometimes you have to use the “oblique” approach. I got more information from friends at server vendors about Storage products than the Storage vendors themselves. The server people fought most of the interface problems.
I have had to get contact info for engineers, Test engineers, Line Test technicians, QA testers and customers to acquire this information accurately. Even this doesn’t get all the possible configurations because no one bought that particular configuration and it wasn’t built and tested. Then it is a moot point.
From this “time” point of view, your Strategy of “make the vendors do it” to win the bid, is the only hope for people in the trenches.
Go and take a look at Jeff Tash’s ITscout site:
http://www.itscout.org/itscout/
It is the most advanced form of the Configuration Roadmap I have found.
Caveat: You can test drive the ITscout product for free but the service is not free.
I see many people falling into the trap of using JBOD-style arithmetic to calculate usable capacity on value-add enterprise storage arrays. Comparing relative RAID, checksum or filesystem overheads (in the case of NAS) is frankly a waste of time in this context.
Most organizations (mine included) spend significant dollars on these arrays in order to satisfy enterprise requirements, not calculate how many MP3′s I can store on a filesystem. My example would be frequent RPO’s for apps like Exchange, or support dozens of dev & test copies for ERP systems, or with dynamic VMware environments (the latest craze) master boot / app images for hundreds of physical / virtual servers.
In those environments, NetApp is the best storage solution we’ve run across so far. The ability to use a fast implementation of RAID-6 (instead of RAID-1) combined with fast snapshot copies of all those Exchange DB’s, ERP DB instances, VMware images, etc… (instead of full disk clones) gives us about a 10:1 advantage in usable capacity compared to our prior SAN vendor. Sounds like a backup-style dedupe pitch, but I’m actually talking expen$ive primary storage here folks!
Oh and Chuck – with all due respect you would do EMC much better service by telling us what EMC offers in this regard rather than disparaging what one of your direct competitors allegedly does not – especially when your negative claims directly contradict this customer’s experiences.
Excellent point bvn! Oracle corp for example uses NetApp precisely because the JBOD they want to use (for cost reasons) is not feature rich enough … yet
I was an infrastructure consultant for Oracle when they first brought in NetApp for the EBSO project a few years ago. My job was to beat them up on performance testing and see if they can survive. Needless to say as per the Pillar discussion above, NetApp passed our OLTP, DSS & Backup tests.
With performance concerns a thing of the past, I can confirm that asset utilization (incl. usable disk capacity, storage network & host server efficiency) was the primary driver for the initial NetApp decision by Oracle.
Using simple terms some DBA-savvy storage guys here can understand – Oracle sees about a 2:1 usable capacity advantage with NetApp because they can use RAID-DP instead of RAID 0+1 as per the well-known Oracle S.A.M.E (stripe & mirror everything) best-practices.
Although Oracle IT has FC-SAN’s from every vendor (EMC, NetApp, Sun, 3PAR, etc…) Oracle’s business units prefer to use lower-cost Ethernet networks for most production databases in order to reduce storage fabric capital costs and storage mgmt operational costs. Finally Oracle uses dozens of DB clones for app dev & testing plus production backup/recovery & DR. It’s here where NetApp really distances themselves from all competitors in terms of snapshot performance & efficiency plus replication robustness and simplicity.
Chalk up another 10:1 usable capacity advantage using snaps and without spending too much time on a formal TCO study you’re already at a 20:1 advantage for NetApp and counting. Did I mention the joy of provisioning DB capacity at the byte-level vs. LUN level?
To illustrate, here’s a nice summary of NetApp’s infrastructure within Oracle circa 2004: http://www.stemmer.de/service/workshops/sng2004nov/download/oracle.pdf
Note how even back then NetApp storage was supporting DB instances of over 10 TB’s and 50,000 users. I’m no longer under contract with Oracle, but I understand the NetApp footprint is substantially larger now, spread out across more Oracle divisions and more storage protocols (NFS, iSCSI & FC-SAN). I apologize in advance if this causes our blogging visitor from EMC some heartache, but NetApp’s “bad marketing” has completely “tricked” Oracle Corp. (and many Oracle customers I presume) for almost 6 years and counting now; unless this multi-PB Oracle deployment of NetApp isn’t “credible” by EMC’s standards?
It seems to me that the basis for the thread is that NetApp are lying to customers.
Based on the fact that the storage industry in general uses a bogus base-10 measure of the number of bytes in a terabyte, I’d have to contend that the industry in general does a terrific job of being imprecise – vendors and customers alike.
Case in point:
When customers ask for a useable capacity, that’s generally what get’s proposed to them.
If the customer neglects to specify how much data they want to store, the headroom they want reserved, how many recovery points and how many to retain, and the growth rate of the data-set (thereby implying some sort of storage layout & system design), then they will get responses that seem ok, but will vary from what was intended.
Most vendors will put in the cheapest solution possible, wait for the inevitable problems (lack of capacity, performance or both) and then have the customer so committed that they have to buy more equipment than they intended (or planned for in their budget).
What buyer wants to say that he or she did a bad job of buying in the first place?
This happens much more often than it should.
Paul,
While some of the feedback (heck, most of the feedback) has taken the form of hostile exchanges between vendors or loyal consumers who prefer a particular platform, the real issue here is whether or not some sort of guide could be created to help a consumer determine usable capacity out of the spaghetti of numbers usually provided by vendors when describing their wares.
I think it would be a great service if such a guide could be created. I just don’t know whether such a guide could be created. That’s my only question and I pointed to the original article to show that, at least, someone is trying to build such a guide.
Simple is better.
With all due respect Jon, I think the desire to simplify usable capacity comparisons for enterprise arrays at this stage of industry maturity is somewhat naive.
It’s all well to compare such metrics between commodity products, but the richness of features and resulting impact on capacity utilization varies so much between arrays from all the popular vendors that this is a futile effort today. We are still years away from the industry consolidation required to bring along the standardization that you seek.
There are some fascinating discussions to be had between now and then regarding what technological, economic and demographic trends will bring that commoditization upon us, but in the meantime there’s a reason the successful vendors gainfully employ such large salesforces to help their clients sort thought it all
bvn,
In the endeavor we hope to at a minimum get agreement on the basic needs, wants and desires.
At the moment everyone seems to have their own solution out of necessity. You, for example, have stated repeatedly that your primary interest is the richness of features. I am sure you are not alone. I, too, desire a FULL, rich feature, function set for every Storage device in use. That feature, function set may not be the same as the one you like, Implement and deploy. They should both be based on the same underlying “Lower Metrics” that drive all Storage. Right now we have a Vendor-based mess.
Your contributions will be valuable and appreciated.
The reply to bvn is purely my personal opinion.
I speak strictly for myself.
I have no official or casual affiliation with Jon Toigo, his organization or any of his endeavors.
I do not speak for Jon Toigo.
You must log in to post a comment.