My Take On ONTAP 8.1.1

This week, rumor has it that NetApp is going to make a big announcement around their new release: ONTAP 8.1.1
 
I work for EMC, so I'm expected to have an opinion, and not necessarily a positive one.  Despite my obvious affiliation, I'm also pretty deep into the storage industry overall (20 years!) and spend a lot of time with customers who use a lot of storage. 
 
And -- in a nutshell -- this announcement is not especially good news.  Particularly for their customers who've been waiting patiently for NetApp to close the gap against viable competitive alternatives.
 
Before long, I can see that many of these NetApp customers are going to have to make hard and difficult choices between whether they stick it out with their current vendor and hope for the situation to improve, or start to look at bringing in competitive alternatives.  And while we could sit here at EMC and perhaps gloat a bit, that's really not what this is all about in my mind.
 
Customer storage requirements and technologies are moving so fast that it's becoming more difficult for even a focused storage specialist like NetApp to keep up.

The Background And Disclaimer
 
I've worked for EMC for 17 years.  For several of those years, NetApp has competed vigorously with part of EMC's portfolio, namely the VNX -- previously the CLARiiON and Celerra. 

The back-and-forth between the two vendors has provided both endless entertainment as well as occasional annoyance for many.
 
The two companies individual strategies couldn't be more different: EMC with its very broad range of storage and non-storage technologies, and NetApp with its mostly singular focus on a single storage operating system. 

While the merits of each approach are discussed widely in the investment community; for customers it's a more pragmatic decision: who will I invest in to help solve my challenges?
 
And, competitive rancor aside, I believe 8.1.1 in its current form is not particularly good news for their customers. 
 
The roots of this go way all the way back to November, 2003 when NetApp acquired Spinnaker in an effort to bring modern file system DNA into their ONTAP environment.  After a few experiments in the 7.x world, the result finally hit the market late last year in the form of 8.1 in general release with some severe restrictions; we now are being presented 8.1.1 as a release candidate.
 
And, after spending a few days getting to know what's in this release, if I were a NetApp customer I'd start thinking about Plan B.
 
Big disclaimer: all of the discussion here is based on a mix of official and unofficial sources.  Some of the specifics here may eventually turn out to be incorrect, in which case I'll come back to the comments section and clarify.  And, while certain EMC product divisions compete vigorously with NetApp, we all sort of like having a tough competitor to go wrestle with in the marketplace -- it makes everyone stronger in the long term.
 
The Big Trends
 
If I were to boil down what ONTAP 8.1.1 is all about, it's about attempting to take ONTAP forward into the modern storage world in three key areas: flash, scale-out and continuous operations. 

Flash storage is a performance discussion; scale-out is more nuanced around capacity, performance and simple operations, and continuous operations is -- well -- really darn important to certain audiences.  None of these are new discussions for EMC or anyone else who's deep into the storage business.
 
So, let's take a quick look at what's in ONTAP 8.1.1 and how it compares to other alternatives.
 
The Flash Discussion
 
Enterprise flash is all about paying less for performance.  Old school: use lots of spindles.  New school: put your hot data in a flash storage device and watch how things fly.
 
Flash implementations break into two broad categories: cache and persistent storage.  They’re not the same thing.
 
Flash as cache has definite value: EMC continues to invest in various flavors of storage caching (FAST Cache and FAST VP on VNX, VFcache, Project Thunder, etc.).  Historically, NetApp invested only in array-based read cache in the form of Flash Cache, formerly known as PAM.
 
With this announcement, NetApp introduces a new array-side caching construct -- Flash Pools -- which are different than what they've done in the past. 

A NetApp array is comprised of one or more aggregates, on top of which are carved volumes and file systems.  A Flash Pool is a read-write cache that's bound to a specific disk aggregate in a NetApp array.
 
This is big for them, because a random write workload presented problems for the classic NetApp filer.  Flash Cache (or PAM) wasn't any help -- it was read-only -- and when the modest onboard NVRAM got filled with writes, classic ONTAP would write to each aggregate sequentially with the expected unpleasant outcomes.  Of course, we as competitors would point this out as much as possible!
 
Now, NetApp customers can upgrade to 8.1.1, and purchase read-write SSDs to cache their traditional disk drives, avoiding this particular problem. NVRAM destages are now done to SSDs, so less bottleneck.
 
Case closed?  Not really.
 
Generally speaking, any money you spend on SSDs under 8.1.1 can only be used for caching -- they can't be used to actually *store* any data in a persistent fashion.  As a result, there's no storage tiering function as you'd find in a VNX or any number of other arrays on the market.

Now, to be totally accurate, you *can* use SSDs for storing data under ONTAP 8.1.1 if the entire aggregate is comprised of SSDs, but that ain't tiering, is it? 
 
I'm sure there will be many statements to the effect that you don't really need storage tiering, or perhaps they hope the name of the function (e.g. Virtual Storage Tiering) might throw you off the scent -- but there are more than a few common workloads that clearly benefit from a combination of caching *and* tiering.  

If you’ve got diverse workloads, you’ll want access to both approaches.
 
It gets more problematic when you realize that the expensive SSDs that are used to implement Flash Pool caching are bound to specific aggregates; they're not a shared or pooled resource. 

Not a big issue if you've only got one or maybe two aggregates, but anything beyond that and you'll have to make some pretty smart decisions about how you set things up, because it'll be difficult to change things -- reconfigurations, moving data sets around, etc.
 
In larger environments, that's a double hit if you think about it: one hit on efficiency (SSDs aren't pooled across aggregates) and a second hit on complexity both during configuration time and manually re-balancing workloads (e.g. copying stuff around) as data access patterns evolve. 
 
Neither issue exists on a VNX, in case you're interested.
 
The Scale Out Discussion
 
Scale-out environments are fundamentally different than the traditional mid-tier storage environments so many of us are familiar with.  Yes, there is a lot more data. 

But little things can become big things simply because of that enormous scale.  Much discussion has been bantered around in the investment community about how EMC's Isilon represents a serious competitor to NetApp in very large file-sharing environments, and there's definite merit to that line of thought.
 
What the investment community tends to miss is an important point: the Isilon product is built from the ground-up as a scale-out architecture -- it's not an adaptation.  That's why we acquired them.
 
And, viewed through this lens, you can see where the scale-out features of 8.1.1 "cluster mode" are targeted.
 
It took me a while to wrap my head around what NetApp is currently doing here, so I'll share with you a quick synopsis of what I understand.   The best source I've found is TR-4078 which recounts the best practices as they stand today.
 
At a low level a NetApp cluster is an aggregation of nodes arranged in failover pairs in a 1+1 arrangement as opposed to the N+M approaches you'd find in natively architected approaches, such as an Isilon cluster.
 
Everything looks mostly reasonable for modest-sized file system access, until you start looking at their approach for large data sets.  Enter the world of “vServer” and the quintessentially named "infinite volumes".  If you want to do seriously large file systems (like an Isilon normally does), there are some interesting restrictions in play.
 
Ready?
 
In ONTAP 8.1.1 to get meaningfully large file systems, you start with a dedicated hardware/software partition within your 8.1.1 cluster.  This partition will support one (and apparently only one) vServer, or visible file system.  Between the two constructs exists a new entity: the "infinite volume" -- an aggregator of, well, aggregates running on separate nodes. 

This "partitioned world" of dedicated hardware, a single vServer and the new infinite volume is the only place where you can start talking about seriously large file systems.
 
While there's some indication that popular ONTAP features (e.g. snaps, compression) are intended to be supported, there's a meaningful difference between snapping 5TB and 20PB.  We'll leave that squishy area alone for now -- as well as compatibility the extended software portfolio -- until we get more information.

Harder to swallow are sobering realities about capacity utilization. 

In addition to the well-understood ONTAP overheads around RAID 6 (er, RAID-DP), right sizing, volume overheads, etc. there's a nice note that you shouldn't let your usable capacity get above 60% if you expect reasonable performance. 

I would view that as a tax on top of a tax. 

And, since we're targeting really big file systems, we're talking about a really big tax.

While the capacity numbers and associated utilization might somehow be tenable, it looks like admins are going to have to start to pay serious attention if they're concerned about performance. 

There's no automatic load balancing against available node and storage resources.  Yikes!

The best practices note goes into some detail about how best to set things up when you do an initial data ingest, but the concerns become more real when you start to realize what happens when you add new capacity -- which, of course, is what scale-out is all about.
 
Typically, when you add new capacity to an ONTAP aggregate, it redirects all new write traffic to that new capacity until it starts to get full, and at some point goes back to a more randomized approach across all available capacity vs. the new stuff you just added.  That means that all that traffic gets funneled to a specific node (and disks) until it hits some watermark – which may or may not be a concern depending on your write ingest rate.
 
And, of course, when you turn around and read it, it all funnels through that same node (and disks) where it was written en masse.  NetApp will point to a round-robin access feature to the various nodes, but that doesn't really help if all the interesting data is bound to one or two nodes, or a limited amount of new storage.  Youch!
 
Compare that with the autobalancing capabilities found on Isilon, and you'll quickly appreciate the architectural difference. 

Only if performance matters to you, that is.
 
There's an associated challenge with metadata handling: all metadata in an "infinite volume" partition appears to funnel to one physical location, albeit a redundant one.  Again, not a problem if metadata usage (e.g. file directory access reads and writes) are within the performance envelope of that particular node.  And there isn't any mention of Flash Pools.
 
Again, none of this is an issue on an Isilon approach -- metadata is fully distributed just like everything else in the cluster.  And Isilon has supported flash drives used as metadata cache for quite a while, thank you.
 
Finally, we've seen NetApp start to position 8.1.1 with prospects as a really big block device. 

Within Netapp, there appears to be some controversy on the merits of this approach in a low-latency block-oriented environment.  Clearly not supported in the vServer/infinite volume world as described above, as one example.

But in a more normal cluster, there's some serious node-hopping going on as I/Os are routed from source to target.  Not really a big issue for patient file-system protocols, or perhaps even moderate block usage.  But as you start talking serious levels of block I/Os, you start looking at potential routes, and you can easily come away with more questions than answers. 

Again, not apparently purpose-built for the task at hand.
 
I feel bad about having to drag you through all this, but it took me some time to understand what the heck was going on here, so I thought it was worth sharing :)
 
Continuous Operations?
 
There are a handful of new features in ONTAP 8.1.1 (e.g. transparent volume migration across controllers) that help lessen the impact of some of the normal disruptions NetApp customers tend to experience, especially in larger settings.  That's a good thing.  Always room for improvement, yes?
 
But to brand their current capabilities as real-deal continuous operations (in the full meaning of the term) seems to be stretching things a bit, especially when you compare them against purpose-built environments from EMC and other vendors. 

So far, the pitch to customers has been "good enough for less money". 
 
That may or may not be the case, but I think it's good to go with a vendor whose capabilities generally exceed what you're asking for, and you can dial things back if needed, rather than positioning every customer for a compromise.
 
Is Compromise A Good Thing?
 
While compromise might be a good thing in the political arena, it's usually not a desirable state of affairs in demanding IT settings.
 
When I look at NetApp's latest release, I see "compromise" written all over it. 
 
Yeah, NetApp does flash -- sort of. 
Yeah, NetApp does scale-out -- sort of. 
Yeah, NetApp does continuous operations -- sort of. 
Yeah, NetApp supports large block environments -- sort of.
 
With this release, it's pretty clear that -- from NetApp's perspective -- compromise is OK. 

Maybe compromise is a good thing for NetApp, since they're up against a strong competitor who looks at the world very differently.
 
The real question is -- how many of their customers will agree?
 
 
 

 

Comments

[DumaDum]

Hi Chuck
One thing I admire about your blogs are the great illustrations you use. May be you should start a separate blog on how you make them and how do readers interpret them.... Apart from that, NetApp is definitely behind the industry on implementation of Flash Drives. This attempt is basically a catch up with the rest. It seems very similar to EMC's implementation of Fast Cache..... Your comments on this...

[Eric Struttle]

Given the fact this blog hasn't dealt with netapp in quite a while, it seems to me there's reason for concern on EMC's part...

and btw...they don't force mirroring for small block requests...like isilon...

[Chuck Hollis]

I'm a storage guy, so I cover storage topics, including (occasionally) competitors offerings. i wouldn't read too much into it. At least,I wouldn't !

[Jane Kissel]

Hi Chuck,

I am interested in you comment "because a random write workload presented problems for the classic NetApp filer." I always thought that NetApp was originally designed to optimize random writes by aggregating disk and coalescing writes in NVRAM?

[Chuck Hollis]

Until NVRAM filled, and then it got ugly ...

[RW Miller]

The comment about forced small block requests on the Isilon is slightly incorrect and could leave a mistaken impression so I would like to address that.

The behaviour hinted at is that if a file is smaller than 128K that instead of trying to use the Isilon's parity protection they just create multiple mirrors of the data to speed things up.

This is not the same thing as forcing mirroring for small block requests. If you only need 16K out of a 1TB file it reads the data from a striped file just as you would expect.

In today's world of unstructured data take a look at your document directories and you will find that there are some files under 128K but that on average most files are megabytes in size.

Really only an issue if all of your files are under 128K in size and in which case hopefully no one would recommend an Isilon cluster to you but maybe a block oriented storage system instead of a filer.

[INDStorage]

Chuck - don't disagree with many of your high-level points on flash and tiering. However, to be fair, any traditional mid-tier array is going to have a challenge with random write workloads if there aren't enough back-end spindles. Forced flush cache conditions on Clariion/VNX are ugly too.

[c]

There is only one thing I hate worse than a rambling contrary blog post ... pseudo-editorial italics.

[Dominic Cody]

Great post as usual and I love the illustrations as usual :o)
My worry about NetApp is the need to buy into the Ontap solves everything idea and I worked for a UK bank that tried it and only got as far as using NetApp to replace group shares and even they are rethinking their decision. I can't really strike with the NAS product we sell (company I work for not EMC) as I don't like or rate it but hey ho.
I do worry about NetApp though will they just die a death or will they be bought and I am not sure anyone will buy them at the moment.

[Cant.]

Well, as a big Netapp customer, I can tell you that although you didn't explain the Cluster Mode well or accurate, Sadly you are right.

I found your article informative and straight to the point, Thank you.

[Eric Struttle]

Isilon Best Practices for vSphere 5.1

"Depending on their overall I/O profile, some
virtual machines whose workload includes small (e.g. less than 32KB per
transaction), random I/O operations may exhibit performance degradation when
using the default protection. These virtual machines may benefit from having their
VM data files configured to use a mirrored (2x) data layout by decreasing write
overhead. This setting can be applied on a per-VM-directory or per-file basis,
leaving other VM directories and files to continue using the more space-efficient
parity-protection layout."

Last I checked, the majority of virtualization workloads are less than 32k and highly randomized.

[Seth Morrison]

Thx for your deep dive into the actual NetApp world. And yes - it's definitely like you commented. NetApp is massively loosing traction regarding new implementation of technology. It really seems that the big years are over and they're more and more trying to keep up with the market.

[nate]

HEY CHUCK! LONG TIME NO SEE

Whew am I glad I didn't get Netapp for my company's vmware environment with a sustained 90% write workload. Our little 4-letter storage system handles it pretty good though I have to admit given the lack of I/O information we were able to extract from the cloud provider I was sort of taken by surprise as to the 90% write number. While I haven't used EMC in some time I do admire some of the innovation that goes on there especially in the flash area - though it's not enough to get me as a customer at the moment.

I'd never really consider isilon for hosting vmware data files - if I was an EMC customer at least on the larger of the mid range size I would probably do some sort of VNX (or VMAX if I could afford it - assuming I was sticking to EMC-only storage) for the vmware stuff and isilon for purely file storage - not transactional.

Since Isilon wasn't designed for that and apparently it shows. One of my former co-workers got hired on to Isilon a couple years ago(he's some sort of manager for support in NYC) and tried to talk me into using it for vmware but that's not gonna happen. It certainly sounds like a nice product, fast, easy to use and stuff but it has it's markets and while you certainly can run vmware with it it's not something I'd consider it for. I have a few other friends at Isilon, given it is a Seattle-based company and I lived there for so long, but haven't kept in touch with them.

NetApp is right in a way I mean you can't optimize for everything - well if you could you'd take the storage world by storm pretty quickly. I was just talking to a friend that is at Tintri for example and he emphasized his company, while specializing in vmware-based storage knows it's niche and isn't trying to go out and be a general purpose array replacement.

So compromise is right - the same with any solution there's some degree of compromise right. Just a matter of your preference as to what compromises your willing to make. Though it would be nice if everyone's marketing was a bit more up front as to the limitations of the system design.

I remember back when I used Exanet - even though at the time I'm fairly certain it was vmware certified the performance of vmware files on Exanet was terrible (Exanet was awesome for file serving though). I mean VMs would completely stall for a few seconds on occasion, once moving them to my 4 letter storage system (which provided the same block storage that our Exanet relied upon - all distributed so any latency on the disks would impact both systems) - no more stalls. I had a cacti system drop it's i/o waits from like 30% to less than 1% by moving that workload off Exanet and onto iSCSI. Exanet was a scale out system, like Isilon (just smaller scale vs Isilon), and it excelled at the large scale file operations that we put it to work performing, just no good for vwmare. Just as I was leaving the company they were in the midst of trying to replace Exanet with a pair of NetApp heads (same back end storage), despite the NetApp heads being 2x more powerful on paper apparently they struggled to compete with the 2-node Exanet cluster, and eventually the company stopped using NetApp barely a year after they bought the cluster.

I do like Compellent's flash approach too - assuming you have flash in one of their boxes all new writes go to a raid 1 flash tier. So it's sort of like a hybrid tier/cache, at least for writes. Apparently Exanet-Compellent integration is coming later in the year. But there's compromises on those systems too, one of the biggest ones for my company when we were looking at them a couple months ago was the lack of direct attach support for FC.

No flash in our systems at the moment, maybe when we grow bigger. Well we have on or two Nimble arrays but that's not scheduled to go to production until next year - and I'm not in that group or on that project.

[Egon]

Most of this article is just FUD outpour while comparing oranges and apples without showing any real technical knowledge. Typical sales fluff. Waste of time.

[Chuck Hollis]

Well, Egon, thanks for your thoughtful, insightful and well-researched commentary.

What a great asset you must be to those around you!

- Chuck

[Dimitris Krekoukias]

Hi all, Dimitris from NetApp...

Interesting opinions from Chuck.

Here are some facts backed by audited numbers, especially with respect to the random writes...

http://bit.ly/Mp4uu0

Thx

D

[Chuck Hollis]

Dimitris:

Long time, no hear!

Congrats on the SPC-1 results; they're better than I would have expected. You're clearly in the league with the other mid-range block devices such as 3PAR, the IBM combos, even an older HDS config. Nice work by your engineering team.

There's a key problem with the SPC-1, though.

No one can look at the code unless they pay money to the SPC; and then you can't disclose what's in it. So customers can't decide for themselves whether or not the test is relevant for their particular situation.

My opinion regarding the relevancy of the tests is the opposite of yours; the workloads generated by the SPC-1 are way too uniform and simplistic to be of much use. Relatively uniform workloads don't benefit from autotiering; real-world ones often do.

And, since neither of us can point to code fragments and/or specific I/O profiles, we can't advance the discussion much past that for the time being.

One question from the results with regards to space utilization, though. Even though you made some statements regarding "full disk surface utilization", the test results show 40%+ of the available capacity unused.

Since unused capacity would needlessly boost your configured price-as-tested, what the heck is it doing there?

My first impression (unsubstantiated, mind you) is that -- once again -- there's plenty of free space available to help WAFL along. Most customers I know don't leave 40%+ of available capacity unused simply to help with performance, unless their vendor tells them so.

The day I see you guys benchmark a near-fully-used system (like most customers have!) is the day I believe that you've changed your ways :)

-- Chuck

[Cujo]

Chuck,

Great post!

Seems highly objective, contrary to some of the comments.

Regarding the 40% free space: as an ex-Netapp customer, I wholeheartedly agree with that - ALL of our systems were utilised close to 90% and upwards..
And as you can safely assume, the WAFL lost its' effective edge..

I might be wrong, but I haven't seen any mention on Dimitris's blog\tests to EMC's machines (VNX family or Isilon)
Why is that so??

Thanks,
Cujo

[Chuck Hollis]

Thanks for the comment, Cujo.

It's not in NetApp's best interests to run meaningful tests against purpose-built EMC products with their general-purpose environment. Based on what I've seen from our own internal testing, the numbers wouldn't look good.

If you distill down NetApp's approach, it's that ONTAP is "good enough" for most of what people might want to do. Essentially, compromise is a good thing.

Example would be the recent SPC-1 results. Although I am most certainly not a fan of the SPC approach as unrealistic vs. customer workloads, you'll notice that they were sort of middle-of-the-pack on the different metrics. All they seem to want to do is be in the game, so to speak.

Notice that they chose a test that presents a relatively uniform workload, which works somewhat to their favor, architecturally speaking.

More concerning is that NetApp ONTAP customers have to think in terms of two, distinct and non-integrated environments that play by very different rules. Almost like they created a new product out of an old one.

Interesting times indeed for them.

-- Chuck

[Iggy Taylor]

Hey Chuck,

We are re-platforming a bunch of enterprise apps (Oracle, Exchange, and SAP) and we are looking at options. How does Isilon integrate with these apps? or should I consider a VNX for this?

Also, is it true that Isilon doesn't have native deduplication and compression?

thanks,

Iggy.

[Chuck Hollis]

Hi Iggy

It looks to me like you're astroturfing on behalf of NetApp. I guess I should be flattered. While that's not technically illegal, it's certainly unethical.

If I'm incorrect, please let me know by giving me more information to work with: what type of business you're in, what role do you play, what are you trying to achieve in your environment, your primary concerns, characteristics of the application, etc.

Otherwise, please go find something more productive to do.

-- Chuck

[Nick Telas]

It is very sad to see one company commenting on another company's technology, instead of trying to make their own products better.

This is clear marketing.

I also see you are attacking Iggy for "misleading questions in favor of NetApp" (is it really so rare very specific for EMC to have Oracle +Exchange +SAP?), while on the other hand it is acceptable for you, an EMC executive, to have your own blog to discuss storage technologies, and finally concluding (surprise-surprise) to EMC superiority.

Try to focus on your own technolgy and people will love it or hate it. People will hate you if you are talking about the other vendor's technology. In fact, this only shows that EMC is worried with NetApp's 8.1.1.

[Chuck Hollis]

Hi Nick

I think you completely missed my point. Iggy (or whoever he really is) was pretending to be someone he wasn't, which is a clear breach of ethics. The question itself was a paper tiger. Conversely, if a real customer or partner has a legitimate question, I'd do my best to answer it.

I respect your desire to see vendors only focus on their own products and nothing else, but we are frequently asked to comment on other vendors and products by customers, partners, prospects and journalists. So that ain't going to change any time in the next century or so.

At least we're clearly labeling our commentary as to who's writing what, so you can decide for yourself-- and not paying people to leave anonymous comments on industry blogs.

Finally, I hope you've gotten some value out of this blog. If you don't like everything you find here, that's to be expected.

[Matt Berkland]

Hello Chuck -- I do enjoy your write up's but isn't this just a bit like the pot calling the kettle black??

I will say that EMC does do a great job marketing things, but let's just use the VNX as an example here. It is a CLARiiON, just remarked over and over again. The user interface may be "fresh" (relative term) but again same old DGC device you have had in the portfolio forever....

Actually, the more that I look at this report it is pretty much just a vendor bash because NetApp taking EMC market share and factually not necessarily completely accurate..... Not even going to get into the whole deduplication discussion.

Note: I am definitely not affiliated with either vendor here, just wanted to put out this comment as the EMC (as does everyone else) have it warts, we just don't get to hear about them in this forum...

[Chuck Hollis]

Hi Matt:

You're more than entitled to your opinions regarding pots and kettles, but I'd like to set you straight on a few facts to base those opinions:

- the VNX was an all-new product for the mid-tier. Yes, it had plenty of DNA from its predecessor products (CLARiiON, Celerra and a few others), but to claim it's a CLARiiON with a new name isn't anywhere close to an accurate portrayal. Ask anyone who's spent any time on one, and they'd likely agree with that statement.

- If you happen to glance at either IDC's or Gartner's market share numbers, you'll notice that EMC has been consistently gaining share in both the broader external storage market, as well as NetApp's core NAS market. In particular, IDC has put EMC far ahead of NetApp in market share for several years now.

- If you'd like to get into the dedupe discussion, well, we should. Both mid-tier arrays have offered dedupe for some time. If you'd like to get into the flash discussion, that's OK as well. Same for VMware integration, Microsoft Hyper-V integrations, etc.

If you think it's relevant, let's discuss!

Was this post a bit of a bash? You bet it was.

They presented a large, obvious target with their new release -- over-promising and under-delivering -- and I thought it was well deserved.

-- Chuck

[Chuck Hollis]

Just a friendly reminder to all ...

Anonymous and off topic comments will be deleted. Please identiy yourself by name or at least a valid email address, otherwise the comment will be deleted,

- Chuck

[Atanas]

Chuck,
You still haven't answered Iggy's questions ?

Thanks,
Atanas

[Chuck Hollis]

Atanas

You're right -- I haven't answered "Iggy's" questions.

The person behind "Iggy" chose not to identify themselves, nor provide a valid email so I could get more information.

You should understand that I've had continual issues with NetApp employees and partners "astroturfing" -- pretending to be someone for marketing purposes.

So, over the years, I've established a policy -- you identify yourself, I'll post your comment and answer your question to the best of my ability.

Fail to do so, and I'll ignore you, just like all the other silly spam that shows up on my blog comment log.

If you don't think enough about your question/opinion/etc. to identify yourself, neither do I.

And, of course, Atanas, since you've identified yourself, I'd be glad to answer any question *you* might have!

-- Chuck

[Mike]

Chuck,

As someone completely independent I support your viewpoint that Netapp have had to and are still playing catchup with EMC in certain areas such as tiering/ caching. Is it not fair to say however that Netapp have also been responsible for many innovations themselves? Is it not fair to suggest that EMC are still playing catchup in their midrange storage product (vnx) in terms of snapshot capabilities? A true unified approach? ( vnxe I imagine is of a similar architecture to how the next gen vnx will be).

Interestingly you stated above that both mid range arrays support deduplication , correct me if I'm wrong but you support file deduplication only which isn't generally a huge benefit. Block based deduplication combined with flashpools on NetApp offer obvious benefits. Can you talk about disk based backup on your primary storage or do you need to throw in another product? Yes the datadomain is great and offers better efficiency than Netapp but at what commercial cost?

I appreciate this post may seem a one sided attack on your offerings but I believe most prefer an honest unbiased approach or maybe none at all? I have to say EMC spend a lot of time bashing Netapp , an indication of your insecurities maybe?

[Chuck Hollis]

Hi Mike

I guess you skipped reading the comments. Unless you identify yourself (real name, valid email, etc.) I reserve the right to delete your comment as just more spam.

But you seem sincere, so let's dive in, shall we?

I need to correct you on a few facts. The product in the EMC portfolio that lines up best with Netapp is the VNX.

VNX does volume (block) compression and has done so for a while. VMAX, VNXe and Isilon do not at present.

VNX (as well as other EMC storage products) support the full range of snaps, clones, replicas, etc. to either the same device as primary storage, or a secondary device, and have done so for many, many years.

Most of our customers consider it ill-advised to store your last-ditch recovery backup on the same physical device as your primary storage, but that's an opinion and not a limitation.

None of this should be especially surprising to anyone who's current on various vendor offerings, so I'd encourage you to at least a bit of preliminary research before forming your own opinions.

As far as "bashing" NetApp -- yep, that's a fair observation. Among all the storage vendors, they seem to be unique in consistently over-stating and over-representing their capabilities, which engenders a response from people like me to take them down a notch or two with the facts.

The 8.1.1 release is no exception. The marketing got way ahead of the product's reality, and even the most die-hard NetApp fanbois are now backing away from the whole sorry mess until it improves.

Thanks for writing.

-- Chuck

[Mike]

Thanks for realising I am genuine Chuck I did infact provide my correct details and don't understand why one wouldn't.

First let me apologise as I said "on primary storage" which was poorly phrased , I was merely making reference to the fact that two Netapp units can provide you with an effective backup solution to meet tight RPO's & RTO's and most importantly recovery SLA's whilst not needing a seperate product to address this. I do research on the storage market every day, it's part of my job and whilst everyday is a lesson one day with a lot of hard work hopefully 'll be fit to shine your shoes.

With regards to compression I am well aware that your statement "If you'd like to get into the dedupe discussion, well, we should. Both mid-tier arrays have offered dedupe for some time" whilst correct was not what the previous poster was trying to state as we all know he was talking about block level dedupe.

Also yes you support snapshots but snapshots are still a big issue for you which is why your reps still avoid the subject. 256 snapshots I believe now and ROFW which means less performance impact, however: you need to enable thin luns which you guys suggest yourself offers a performance hit. Also , application integration on VNX snapshots? Integration with replication technologies?

All in all Chuck it's most likely swings and roundabouts, you have a great offering as do Netapp. Two great storage vendors with two very different sets of values.

I have to say I enjoy your blog and the exchanges that follow each post , it's good to have competition and long may it continue! The kind of camaraderie that both EMC and Netapp have in their ranks is something that every company should strive for.

[Christopher Waltham]

Chuck, given your post against astroturfing (something I am also against), would you be so kind as to request "Dr. Scale-Out" to out himself? You can see him in the comments in my blog, here: http://bitpushr.wordpress.com/2012/07/20/why-efficiency-matters-netapp-versus-isilon-for-scale-out/#comments

I will always identify myself as a NetApp employee and I'd appreciate it if competitors' employees would do the same. I welcome any and all discussions about storage technology but let us at least do it openly and honestly (as you support).

Many thanks! Chris, NetApp employee

[Chuck Hollis]

Hi Chris

I agree, this looks like an EMC employee from what I can see.

I'd like to help, but it's going to be a challenge, as I don't have much to go on. EMC's official policy on such matters is crystal clear and unambiguous, e.g. identify yourself and your affiliation.

If you would be so kind to suggest to them that (a) they appear to be employees of EMC, and (b) are thus bound by EMC's policies which can be found on the video in this blog post:

http://chucksblog.emc.com/chucks_blog/2011/06/celebrating-social-media-at-emc.html

Thank you!

-- Chuck

[Jan]

Chuck. In about 5 years time, if people are still managing disks, luns, fibre channels for your product (EMC) then your product is a failure. I hope u understand what Continuous Operation and Management really means for customers :)

You don't want to manage storage, you just want your storage to be as dumb as possible, and that's not happening with EMC, not anywhere close in customer's opinion. Tell me what's the latest innovation you got for manageability?

[Chuck Hollis]

I think you've set a record for the maximum number of uninformed comments in a minimal amount of space.

EMC has multiple storage products: block, file, object, dedupe appliances, SMB, etc. Which one(s) were you referring to? Most of us found NetApp's implementation of "continuous operations" a partial implementation at best, and very overstated in terms of actual customer benefit, especially when compared to competitive alternatives. Compared to something like VMAX (or even HDS's product), it's weak sauce indeed.

I think that everyone would agree that storage should need to be managed as little as possible. But that generally indicates the need for storage (and its integration with the surrounding environment) to be as smart as possible, vs. "dumb" as you claim.

EMC brings new storage management innovations to market on a regular basis, and you'll find many of them detailed here in this blog. In addition to a great deal of VMware and Hyper-V integration, there's serious innovation to be found in Unisphere, Prosphere, the new DataBridge, Data Protection Advisor et. al.

Surely you have something better to do ...

-- Chuck

[Shehryar]

Hi Chuck,

The organisation has a total of 1,964TB of data in NetApp filers. It has 22 FAS 3040s, 10 FAS 3140s and 24 FAS 3240s running predominantly SATA drives. These devices comprise four nodes in the NetApp Data ONTAP cluster which support Oracle databases – including one with 4.1 trillion rows of data – running on HP servers via a 10 Gigabit Ethernet LAN.

http://www.computerweekly.com/news/2240166364/CERN-turns-on-new-NetApp-ONTAP-clustered-NAS-capability

I visit often and often I read about you targeting netapp and ontap ... We are also a Very Very Happy NetAPP Customer. We have had no problems whatsoever (touchwood) with netapp as of yet. We have got 40 storage groups of our exchange environment hosted on netapp, with vmware (the best integration with vmware) it's a very good product and it is sad to see from a person of your position to talk about data ontap like the way you are pointing out. its like a classroom full of kids fighting on whose right or wrong - I have nothing against EMC, I think they are a great company.

At cern the amount of data is massive and you can read the rest all by yourself - not to mention that some of the netapp boxes they are using are considered Mid-range.

Readers should also check Hitachi - http://www.hds.com/assets/pdf/victoria-and-albert-museum-success-story.pdf

Hitachi data systems is the most supreme in enterprise storage industry - they have got some amazing products too.

EMC has the great marketing machine :-)

Chill chuck ! You should write about the intelligence of EMC VNX, file system and their technologies.

ALl the best !!

[Chuck Hollis]

Hi Shehryar:

Yours has to be the most - err -- colorful comment I've gotten in quite a while. While you seem to be quite able to cut and paste press releases, it's not clear, I was unable to determine what company you work for, what role you play, etc.

You seem to think comparing different storage approaches is the same as bantering about sports teams at the bar. Trust me, for many larger organizations this is very serious stuff indeed.

Good luck in the storage world ...

-- Chuck

[Shehryar]

Hi Chuck,

Thank you for your reply. Yes I cut / pasted the press-release, Why ? Because I felt that with this blog-post people may get the wrong idea of Data OnTAP or netapp products. Also, I wanted to briefly tell people that there are good points about netapp too, just like emc have there pros and cons.

Also, that CERN which doesn't discusses storage like sports teams in a bar, must have done their investigation and evaluation before relying on NetAPP storage with their very critical data and research. given the fact that CERN is one of the most reputable research centers.

Also, I visited your blog often with the intention to read about EMC technologies. What do they offer etc.

Also, to your following comment :

"You seem to think comparing different storage approaches is the same as bantering about sports teams at the bar. "

No, I understand this is very serious business as my company evaluated different vendors for 6 months and went through all the planning and evaluation required. I was only part of the team and learned alot and I am still learning about storage technologies and getting hands-on experience as well. we discussed that in our meeting rooms and we have got a good exchange and vmware environment.

Your assumption about me on my first comment ever on your blog tells a lot - Good Luck with that too :-)

Which is why I commented, I want to read about EMC products and their strength and weaknesses on this blog. but all i came across was data ontap being insulted :-)

I wish you and EMC good luck too. EMC is a very good company too, and i have no hatred whatsoever against them !

Shehryar
PS : I am only a 2 year old in the storage industry and have always wanted to learn new technologies, why do you think I come to this blog :-). Will be great to see some of your future posts (whenever you get time) about EMC's Strengths and some sort of pictorial representation, their weaknesses or room for improvement. What does EMC calls their Operating System? Which one of them is responsible for Block and which one of them is responsible for File etc. and all of this post is not a cut / paste ! Have a great and winning day / week / month / year !

[Ian]

Chuck,

I think you should also mention some of the features that are lost with cluster mode like Metro Cluster and Sync SnapMirror and SnapVault. How can they release a new product with less features than the previous version which a lot of their customers are staying with for the time being.

[Mark]

Funny how snapshots work with Isilon. They are not sub-file. You snap a directory with Isilon, and if you change one little byte on a 100MB file, a full 100MB copy is made. snap it again, change one more byte, and other 100MB copy is made.

Has anyone ever drawn a picture of how protection groups work in Isilon, with all of the block#node#offset#run pointers directly within the file inode? It is simply impossible to update anything. Even if you could, every copy of the inode (which is independently copied to maintain a certain protection level) also would need to be copied...

None of this is cool. Reading the Isilon docs and how they avoid talking about this behavior isnt really all that honest. Isilons cannot support more than 2,048 snapshots on a cluster-global level by default, and the best practice documents strongly advise against raising the global limit to anything above 4,096. Its obvious why this is a problem – imagine the penalty of thousands or millions of files needing to be copied, not just on the storage efficiency but also the performance.

EMC has no business comparing Isilon's snapshot capabilities to NetApp. Isilon is built from the gound up as a large fixed file scale-out box. Lots of cache and a very NetApp-like nvram teases the community that it might be something more, but it isn’t.

[Diego]

We cant expect nothing different, the post is from an EMC guy so... A lot of FUDs otherwise why IDC
Named NetApp as a Leader in IDC MarketScape: Worldwide Scale-Out File-Based Storage 2012 Vendor Analysis?

[Chuck Hollis]

Hi Diego -- a net fanboi! Not many of them left these days ...

My suggestion would be to have you download the entire IDC report, study the evaluation criteria, and then maybe come back here so we can have an *informed* conversation.

Cheers!

-- Chuck