Features are constraints in Netapp

I've spent some time having a read through some posts at blogs.netapp.com, and I happened to find a surprising one, featured by Mike Richardson in The Drop Zone. Here's the link to the post.

Mike says: "A lot of strange speculation and chaos theories have occurred lately in regards to NetApp's tiering strategy.  Maybe I can help clear up why NetApp is not so dependent on tiers as our competitors."

Haven't seen any chaos theories referred to Netapp so far. In fact my perception of Netapp is positive as a first line role player in storage. No chaos or Universe breakdown to be addressed. But stating not to be tier dependent is a curious way to explain that tiers are a pain in Data Ontap for several reasons.

Tiering is a feature, which means it tries to satisfy some type of demand or market need. In this case, tiering helps to reduce the cost of data storage, as data changes its value moving forward in the Information Lifecycle. Well, I see no dependency on offering a clear tiering proposal for customers.

My suspect is more marketing centric than tech driven. If the messaging is focused on denying the value of tiers as a feature, other features related to tiering will subsequently loose value. Let's say, for example..ermmm...FAST?.

Following on, Mike states another surprising idea: "The present day effects of these approaches are now very apparent.  NetApp has a highly unified and efficient storage operating system that can maximize the capacity and performance specifications of the underlying hardware."

I would appreciate being introduced to such operating system and such software refinement. Mike can't be speaking about Ontap and WAFL. Seriously, this just can't be. I mean, I like Ontap, but is far from efficient from the capacity point of view (same can be said for WAFL), and, well, as long as your disks are reasonably empty, is fast. One thing I must recognise: snapshots are just ... gorgeous. Great!

Mike, why not instead of messing up leaving unused blocks all over in order to obtain a sequential write in the first space available, you fix up you caching algorithms? as an admin, it would be a relief in my work not having to go through some compacting processes permanently.

If we have to believe that system factory defaults are allways set to the recommended manufacturer values, the disk overhead you get just by leaving those defaults leaves a usable space of (roughly) 47% of the raw space available. Add to that the mess with blocks to achieve write performance and you'll get a clear picture of how effcient the system may be. Anyway, I like it.

So ,dear Mike, I will not go through large raidset risk considerations for today, but I will be happy If we both just agree on the fact that features are features, and constraints are not.

Cheers!

Juan

PD: Tried to post a comment in your blog, but it seemed to disappear. I tried my own blog... it works! ;)

Comments

[Adriaan]

Juan,
Everything in this world is based on your assumptions.
The system defaults are set that way to eliminate risk - not for peak performance or efficiency - to achieve that requires admin decisions and monitoring which when done - As we have on hundreds of systems - removes the issues you refer to.
Second assumption - that teiring has a fixed value - it does not, it is relative - and therefore there are some environments where it is of lesser value, and thus not as desirable. There are also alternate options which may be more desirable.
I for one prefer a storage landscape where we have a number of storage players which actively seek to travel different design strategies, as in that way I am able to choose those that fit my requirements for each different client.
All journeys are different if you start and end in different places.

[Juan Jose Palacios]

Thanks for your comment, Adriaan.

I definately agree on the different vendor issue, this reflect many ways to solve different issues, thus permitting evolution. This moves us forward.

I must state, in many aspects, I have enjoyed DOT. And I still enjoy it ;)

But my criticism comes as an answer to a precise statement "...not so dependent on tiers...".

Under my point of view, this doesn't reflect a real situation, so I believe is a misleading comment.

Tiering, as I stated, is a feature. And in many cases is a strategy (when you decide to use that feature as a policy mainstream). Allright, use it just if you need it. That's all it takes.

But, honestly, I do not believe this can be called dependency.

Cheers