EMC 20% Unified Storage Guarantee !EXPOSED!

Nick Triantos May 20, 2010 at 3:48 pm

Hey Chris…

Your example seems “normal” to someone who's in the business for creating non-intelligent Application silo's…So I have a few simple questions for you.

How many NetApp customers do you that:

a) Do not use Snapshots
b) Don't use clones (Flex or Lun Clone)
c) Do not use deduplication, even for part of their data
d) Deploy only Home Dirs
e) Do not deploy Databases, Virtual servers, in combination with NAS data
f) Is an EMC RAID 5 14+1 configuration, a typical, or a best practice config, for ANY EMC storage array. Reading at Best practices this does not seem to be the case. That's not to say that it can't be done or it's not supported, but does a typical EMC customer use a 14+1 RAID 5 RAID Group? I think we both know the answer to this…

Essentially what you have shown is how to make NetApp array look like a dumb box of disks in order to compare it to a less intelligent architecture. I must admit you do have the upper hand…

What i'd really like to see is, and i'm sure you readers would too, is not a comparison between Raw/ Usable but rather a comparison of the Overall Storage Efficiency between the 2 arrays given that at the end of the day, customers do use snapshots, clones, flexclone and deduplication with NetApp, and generally speaking, they are more interested in the utilization and efficiency of their storage infrastructure as it pertains to their day-to-day operations and their needs. At least our customers do…

So let me ask you this, If EMC provides X TB usable and NetApp 20% less, and NetApp turns on dedup, snapshots and clones who do you think a customer will consider more efficient? The one who sold him 20% less usable storage but saves him at least 2x of additional capacity thru intelligent techniques to accomplish their day to day business needs, or the one who sold him 20% more usable storage?

I, also, find it bizarre that you talk about space efficiency techniques like thin provisioning, snapshots, compression, yet you provide comparisons of Raw/Usable. I think your readership would be most interested on more important things like what their costs will be over time in terms of managing distinct architectures, how efficient the architecture is in terms of *storing* the data, and what their savings will be.

Btw…Howcome a “Unified Storage” uses disks for 2 separate Operating Systems?

JK May 20, 2010 at 4:56 pm

Nick – GREAT points…

Except for one thing, that's 20% efficient BEFORE they turn on the efficiency.

What is that you ask? Well, Checkpoints (snaps), thin provisioning, Fully Automated Storage Tiering at the sub-LUN level, live file system deduplication AND compression (not only file shares but individual VMs).

What button do I click on a filer to dedup a virtual machine again?

So all of those things you mentioned are very important to most IT organizations. Although the names are different, it seems that the EMC Array has all of the features you mentioned.

All of this from a single, VMWare enabled interface that provides visibility to the disk level to a VMWare admin from the VI client while at the same time providing VM level visibility to the Storage Admin.

Efficiency is much more than just $$ per gigabyte – but if we're using that yard stick, EMC is 20% more efficient out of the box BEFORE they start getting efficient.

You might want to check out the demos:

https://www.pkguild.com/2010/05/everything-i-nee…

John Martin May 20, 2010 at 6:32 pm

I thought I'd run some comparisons of my own using the sizers that the engineers use.

If you start with 210 TB (RAW SNIA Base-10 TB) on a NetApp array with one hot spare and no snapshots and RAID-4 (same as your final FIle+DB example), you end up with 155.726 TiB (Base-2 Usable Tibbibytes, which I think you've shown as TB on your example). This works out to 73.8% which is a little better than your best case figures for your “Unified Storage”

Of course this is a completely bogus configuration. The people I've met from EMC care about their professional reputations and their customers data, and I strongly doubt any of them would ever reccomend or implement a configuration like that. It's interesting marketing, but completely divorced from the real world.

As far as the email/collab figures go I assume you're configuring this in a traditional SAN configuration.

The interesting thing about these traditional SAN's configurations is that they have a long history of being terribly wasteful in the way storage is allocated, with typical figures of 40% of the space being wasted/unused/overallocated in little LUN based islands of storage. It is this 40% figure that we assume will persist in our configuration as well as that of other offerings unless you use techniques like thin provisiong. It seems like the way you are using your sizer assumes that people will use their storage with 100% efficiency. If you take this out of the equation, your purported 40% advantage simply isnt there.

Of course going with a traditional SAN configuration will save you about 10% vs a more modern deployment Dart/Ontap due to the in built space reservations included to provide fine grained storage virtualisation. Fair enough, but the world has moved on, and to get the advantages of dedup, and compression and cloning, and thin provisioning, and high performance snapshots, you generally have to give a little capacity to the storage virtualisation layer to make this work gracefully.

You could also argue that you should be sizing these solutions based on IOPS, not just capacity, but if we did that, we'd probably be looking at SATA for Exchange 2010. If you want to tell customers to do old school thick provisioning for sharepoint without using any storage efficiency features thats fine by me, but dont be surprised when you lose deals to NetApp.

If you'd like to put up something resembling a real customer requirement including IOPS and data protection requirments, I'd be happy to size up something for you. In the mean time, keep an eye out for the next revision of our storage efficiency calculators.

Jonas Irwin May 20, 2010 at 10:50 pm

Bottom line: “EMC is more efficient before we even start getting efficient”

Maybe EMC should have created a real 300% savings guarantee based on telling customers to over provision their luns and file systems by 300X with EMC thin provisioning? Perhaps that would be more valid :-)? Extreme example..but hopefully that illustrates the point here.

Funny how ntap folks try to change the subject and point to their layered technologies to turn the attention away from the massive space deficit that their customers must start with on their kit, particularly in the block storage world. Yes, there are editorial docs about turning off all system safety nets but they are there for a reason. How about “If you want more space savings out of the gate, we can auto delete your backups..(ouch)”. Any vendor can rig a guarantee and draft nearly 100 pages of confusing caveats to achieve an artificial savings number compared to something that rarely exists in the real world– for example an all RAID 1/0 config. 80% of the RAID sets on EMC systems run RAID 5 and enjoy more than 5x9s because of proactive hot-sparing , checksum and sniffer technologies. On a JBOD, double disk failure happens with R5 but I’ve never seen even so much as a parity rebuild happen on a CX3 (or above) platform in my 3 years here. We can do RAID 6 too and hit the number just fine as well. To derive savings out of dedupe to meet their imaginary guarantee numbers, customers must delete or exclude all database data, encrypted or image data that is beyond 10% (or is 20%?) of their total data set. Is that where some of the space savings is coming from ;-)?

The idea with the EMC guarantee is simple..use system defaults and achieve 20% or better savings without earning a PhD from vendor caveat school ?. EMC is taking a “customer first” approach that prevents us from forcing the customer to become an expert in understanding a litany of so many confusing caveats (96 pages), that they just give up. Why not just allow the customer to power the box up, create some file systems and luns and get massive savings out of the gate? From there, they can absolutely layer on thin, dedupe, compression and FAST to achieve orders of magnitude more savings. In fact, to achieve a even better number EMC midrange system allow customers to consolidate 3 different types of disk into a single pool. From there FAST will autonomically balance the workload for space and performance with a simple, easy to use policy. Not all apps are thin friendly, not all apps and data compress or dedupe well, so the only way to unequivocally guarantee a savings number around those features is by adding a mountain of caveats. The more caveats you have, then more customer agnst and confusion results. Forget it..it’s a waste of everyone’s time! If you're starting from a much more efficient base, you don't have to force your customer to exclude data sets, figure out how and when to run post processes like dedupe across say, 200 volumes. Also, aren’t snapshots and writable snaps included in their savings number (when compared to full clones) but it’s operationally very complex to have both dedupe and snapshots on the same volume without cancelling out the benefit of either. This ends up being an “OR” rather than an “AND”. I can’t mention the names of the large list of customers who’ve found the EMC gaurentee refreshing just yet, but there are more than I can count on 4 hands right now ;-)

Jonas Irwin May 20, 2010 at 10:55 pm

John – are you saying that ntap guarantees are real world and take both performance and capacity into consideration?

Jonas Irwin May 20, 2010 at 11:08 pm

Why does it matter if emc has two operating systems – one for nas and one san if all customer requirements can be met and they are all managed through a single pane of glass?

Nick Triantos May 21, 2010 at 7:26 am

Why? Well lets see…

1) Because you need a few different ways to replicate depending on what protocol you are using
2) Because different ways to obtain snapshots depending on the protocol
3) because there are different processes to patch each side which is more time consuming
4) because each product has its own separate volume management and space is split between the NAS/SAN function making it almost impossible to reduce one and allocate it to another
5) Because fault isolation and troubleshooting can become more complex when dealing with disparate architectures that have been tied together
6) Some important features are only available for the NAS side only and maybe iSCSI

All of the above contribute to increasing customer Operational expenses. A single pane of glass, while a valuable tool, does not eliminate the fact that customers are dealing with disparate architectures.

Chuck Hollis May 21, 2010 at 10:39 am

Just checked over here, and — boy! — are some people pretty worked up. All I can do for the NetApp folks is share some advice — when you're in a hole, stop digging!

Mailbotx May 21, 2010 at 12:58 pm

Netapp has two operating systems too, 7G and GX, but you can't run them both together (if I understand correctly). Have to agree with the other comments, what does this have to do with capacity of the arrays?

Eugene May 21, 2010 at 3:13 pm

Hi Chris,

You and I have met a few times both in your prior role and in your current one. I respect the breadth of your experience, but this post feels somehow intellectually dishonest when viewed from a customer perspective.

Dedupe has arrested our VM growth by 90% (easily 3/4 of all growth in our environment). Removing space-reservation from existing LUNs and volumes gave us back 40% of space that wasn't being used. We're going to start cloning for dev/test soon and reduce our footprint even further, and everything is thin-prov going forward. We mix and match protocols and tiers between different hosts and even on a single host through the same command-line and the same management concepts.

In two years, we have not bought a single additional spindle even though from a host-side perspective, our environment has easily doubled.

So while I have no doubt there are better raw capacity numbers out there (Seen Equallogic lately?), they just don't matter much to me as a customer (unless its cheeeeeeep!), if I'm drinking the Kool Aid properly.

My guess is this post wasn't aimed at current NetApp customers, but I can't help but chime in with my real world non-consulting non-sales non-consulting-engineer experience.

Of course, I haven't had a single experience with EMC kit, and would love to hear the same points as you raised from the perspective of a customer.

Best,

Nick Triantos May 21, 2010 at 7:59 pm

Scott,

Just because an argument is old, does not mean it is not relevant. By claiming it as “old”, you are really dating your architecture. :-)

I find your disk tray analogy quite interesting but you might want to rethink it because regardless of whether you're dealing with physical disks, or are juggling balls in a circus fewer is always easier…

If having a single management pane in order to manager *dissimilar* architectures is what unified storage means to you, it stands to reason that having a single way to replicate storage also makes a lot sense or having a single way to snapshot across different protocols or even having a single Site Recovery Adapter that works, natively, across arrays. At the end of the day, having a single replication strategy means there is also a single DR strategy for all storage regardless of protocol…

A manager who wants an array that supports all protocols should not have to learn different tools to perform the same task, and should not have to understand different replication mechanisms to do DR.

Compression/Dedup…Although both are space efficiency technologies, the method within in which these efficiencies are achieved are different and yield significantly different results. Let me explain:

1) Deduplication

Lets assume I have 10x 10GB identical vmdks. When you deduplicate you'll end up with 1 copy with 9 links pointing to it, resulting in 10GB of disk consumption

2) Compression

Again, I have 10x 10GB identical vmdks, when you compress, lets say you compress at a, absolute best case, 2:1 ratio (highly doubtful because compression works at the single file level and not across files), anyway, you'll end up with 10x 5GB vmdks resulting in 50GB required capacity NOT 10GB.

Some vendors implement a combination of both. Do you know why? Because at larger block sizes, dedup yields very small returns, so it is passed to a compression engine, again, at individual file level.

In case you haven't noticed, ONTAP 8 contains the foundational elements users need to build scalable virtual storage environments. Although our scale-out GX platform has been available for a while, we've really held off on pushing it until it was integrated with ONTAP and could leverage features such as SnapMirror, MultiStore, etc. In fact, as we’ve publicly communicated that 8.1 is where the rubber meets the road…what does your convergence roadmap look like?

Brad Elberman May 21, 2010 at 9:00 pm

Chuck, Time to Quit. Your statements below to storage guarantees.

“Personally, I detest marketing initiatives that prey on people's lack of familiarity with certain topics.”

“Despite the fact that EMC abhors this sort of gimmick, I offered that for many years EMC has offered a storage optimization service where we come in and look at process and procedure with the goal of reclaiming underutilized storage. Sometimes we do this on the basis that we'll find more storage savings than the service costs, so you don't pay unless we find the pony.”

” If EMC were to do something similarly tacky, I'd probably quit in protest.”

In other news, Paul Maritz, CEO of VMware, partially owned by EMC had not been reading Chuck's blog either because VMware last April also announced a guarantee program with Chuck publicly stating he “didn't particularly agree nor approve VMware's program but my opinion does not really matter because VMware operates as an independent company.” Fair enough.

But now that EMC has put in a Guarantee program and Chuck's opinion DOES matter, he makes no statement on his blog….Looks like someone's in a hole…

John F. May 23, 2010 at 7:08 pm

Unless the aggregate is used for sync snapmirror or metrocluster, the 5% aggregate reserve is routinely removed. Even if you keep it, it's typically 1-3% instead of the default 5%. Snap reserve is typically set to zero, and you provide space in the volume based on your change delta and retention. It's been years since it was 20%. The Clariion uses 10%. Can you or should you change that? At what change delta and snapshot retention is the Clariion assuming 10%? How much does Celerra add to that? But you knew that anyway…

Hope things are going well in your new gig.

Mike Riley May 25, 2010 at 2:21 am

In related stories:

EMC has added beer taps to all arrays and renamed their firmware to “Information ONTAP” and their filesystem to Belgium Pancake.

EMC has pre-announced that whatever NetApp's next guarantee or innovation is, people should immediately consider it “shenanigans” until such a time that EMC pre-announces that they themselves will launch a similar program. (On a side note: no one will inform Chuck – again. Seriously, Chuck, you should probably just focus on a follow-up blog for the iPad until this blows over.).

EMC admits that their sub-lun level FAST v2 is a data-randomizing fragmentation engine that degrades system performance over time, apparently in an effort to pattern themselves after their mistaken belief on how WAFL really works.

EMC Sales teams across the U.S. are required to enroll in training on how to say “Unified Storage” without making air quotes with their fingers.

And, finally, Joe Tucci announced to his family that he is changing his name to Tom Menwarmenhitzen.

Love the guarantee, guys, and the passion. Competition is good even if your NetApp spin is abouat as accurate as these other stories. If EMC guarantees 20% savings on their legacy arrays with a couple of bolt-on products – great! If you really want to bolt something on to those legacy arrays, try a NetApp V-Series. We'll guarantee 35% savings with EMC's own disk. You can add some NetApp storage to that config and we'll guarantee 50% savings on that. At the end of the day, customers can take a look at both approaches and make the call and we're more than willing to have that discussion now that you bring it up. We appreciate the additional attention on this topic of storage efficiency. Now, let's have at it in the market.