Storage Efficiency Insights in NetApp BlogsWhere is place located?

Log in to ask questions, participate and connect in the NetApp community. Not a member? Join Now!

Recent Blog Posts

Refresh this widget

I was a psychology major in college.  I picked up Computer Applications only because I had to fill my schedule with electives and it seemed like a good fall back plan.  A buddy of mine said I would at least give myself an option to get a job in a hot field and I could always go back to grad school or law school.  Turns out I did go back to school (business) but I'm still fascinated by people and why we make the choices that we do. 


Technology is a choice - how much or how little you want to consume of it.  I've seen a number of articles talking about how human behavior is shaped by technology.  Hard to disagree with their specific points but, it's way too Pavlovian for me.  Although, walk into a conference and you'll see highly trained  technologists react (almost sub-consciously) to every bleating whistle, tweet, bell, and ringtone.  Might as well set up drool buckets.  In spite of this, I don't think iPhones or laptops or tablets shape our behavior.  They're clearly a response to how we would like to behave.  Seems like a no-brainer but most of the articles I read talk about the merits of the technology.  Little or no time is spent talking about if people would feel the technology offers a personal benefit to them.


Example: As an SE I thought I had just given my best presentation on the glories of Snapshots - ever.  I had hit all the value props - fast, zero performance hit, instant restores, space savings.  It was kind of a "ready, fire, aim" type of presentation so we circled back around to what was really the issue.  Turns out, the customer had spent the last two weekends and the previous night wrestling with restores.  His wife was getting pretty ticked off that the job was impacting home life.  All the customer wanted was a solution that could get him home on time.  Everything I had said up to that point: no impact.  I never connected the dots between the technology and his motivation.  I could have spent the last 45 minutes talking about windmills as long as the punchline was "and it will make sure you get home to the family early." 


I'm not discounting analysis on technology trends, specifications, TCO, benchmarks, etc. I think good ideas succeed when they address human motivation.  When I joined NetApp (Network Appliance) the catch phrase used to be "Fast, Simple, Reliable."  I still like that because it was very easy to make a connection with the customer.  Nobody wanted slow, complicated and unpredictable.  It was easy to plug in to the sentiment that if you can make my work life easier and less complicated; that it would do what you said it would do, I would have time to do what I really loved to do - whatever that was.


So, with that in mind, here are a couple technologies I think are good ideas doomed to fail:

  • Hard Drives - great idea.  Fantastic idea.  They have served us well for decades.  Flash changes everything and the biggest casualty will be hard drives.  I don't think they will go completely away. There's always the consumer market!  But, hard drives are about as reliable as they are going to get.  Data integrity isn't keeping pace with increased density.  Random access times haven't changed. You don't see storage too many storage startups using HDD platforms anymore.  The number of flash vendors has quintupled over the past few years.  Enterprise storage will soon be all-flash.  It's not because the technology is cool.  It's a cost thing.  Why pay more for less?  Unless we start thinking that hard drives are a cool vanity purchase, HDD are on the way out. 
  • Automated Storage Tiering -  First, flash kills ATS as we know it today.  Why tier disks if all you have is one tier: flash?  Caching still makes sense.  ATS does not.  Second, like all of its ILM predecessors, ATS sounds really cool on paper but at the end of the day people will take a pass.  We can't be bothered.  It's an atomic ice cream scoop.  It's football season and I'd rather watch a game than figure out tiers of storage or read through a few hundred pages explaining how to carefully set up what is supposed to be the technology equivalent of self-leveling cement.  If it were just as easy as "just add water" and pour, great.  It's not.  And, the savings just aren't there.  Storage depreciates faster than you can tier.  Eventually people get tired of generating reports justifying a decision that should have been self-evident.  That's usually when you see someone belch forth a TCO report.  Anyone download a TCO report from any vendor on any technology that says their technology is a bitch to manage and costs more in the long-run?  Nope - they don't exist.  Tiering won't compete with the lower cost and "Fast, Simple, Reliable" message of flash.
  • Thin Provisioning - we're lying to ourselves. I know that's not in the marketing literature anywhere but, that's all this is.  It's technology fiction.  We've invented a technology to help us get over trust and honesty issues.  We're essentially lying to our users in order to drive utilization up.  At some point we get tired of lying to ourselves.  The truth is so much easier to keep track of.  We'll eventually get tired of this.  Someone at the top will just say, "Look.  If utilization has been at 80% for the past three years and nobody seems to be worse for the wear, can't we just give people what they actually need and report on what they actually use?"


Just a few ideas that I think will go the way of Betamax.

VFCache – Man, am I conflicted over this announcement.  On the one hand, I applaud it.  Here you have a market leader addressing a trend (host-based flash cache) with a lot of potential for customers.  That’s great. That’s what you want to see out of your vendors.  On the other hand, if I net out the actual product (and EMC people, I can stand to be corrected but it’s all I could find as far as technical details go), I come up with this:


If you have a FC-only SAN (any SAN; no unique EMC array value here), non-virtualized, high random read, small working set application where cache coherency/data integrety isn’t a concern, then a proprietary VFCache card (limit one per server) is for you!


Wow - there’s lowering the bar for market entry and then there’s just laying it on the ground so you can step over it. Even with all of the app hype in EMC’s presentation, I was hard-pressed to come up with a good use case. 


I even got a good chuckle with the Thunder pre-announcement.  In a rare vendor triple lutz, EMC announced VFCache in paragraph one and pretty much gutted it with the Thunder announcement in paragraph two.  That had to be a new land speed record for obsolescence. If not obsolescence, it will be interesting to see how EMC stitches this all together in the coming year.  But, it’s pretty clear that there wasn’t a lot of “there” there today.


Now – all that said – I still like the announcement.  I’m not crazy about a low/no-value v1.0 product as a conversation starter but, there is something to be said for having that conversation.  With all of the big brains running around inside NetApp, I sometimes wish we wouldn’t play things as close to the vest as we do.  Almost a year ago to the day, NetApp previewed its project Mercury at FAST ’11Chris Mellor picked up on it in The Register.  Other than a few other mentions here and there, you didn’t see a lot of press on Mercury from NetApp; not a lot of chest thumping even as it turned into a hot topic for customers.  I will say if you want to hear the latest-greatest on Mercury, you can ask your local sales team for an NDA meeting.  We’ve been sharing the info under NDA and as I’m sure EMC, Fusion I/O and others can attest, it resonates very well. 


Another interesting facet to the EMC announcement is the central role that caching is taking in its AST strategy.  Let’s face it, FastCache was meant to remedy the glacial data movement issue of FAST (and, quite frankly, as a reaction to NetApp’s Flash Cache).  However, once you’ve plugged in to a caching strategy, it’s easy to see the logical next steps: moving an intelligent cache closer to the point of attack.  We talked about the inevitability of a caching strategy in the blog Why VST Makes Sense and the next logical steps in The Next Step in Virtual Storage Tiering.  There's no question that intelligent host-based caching is a great next step and a logical extension of a VST strategy.  (Just wondering how long it will be before EMC adopts VST as a strategy?)


I actually think there is a balance that can be struck here.  I do think there’s value in promoting your ideas on how to best solve customer problems.  From that standpoint, I perfectly understand the EMC announcement.  But, I also think there’s value in delivering a solution that has practical value to a customer.  What’s practical about the VST strategy?  Well, the great thing about caching is it just works.  You don’t have to worry if caching works across protocols or if it supports advanced application features.  You wouldn’t even have to worry about which cache card, necessarily. Flash is hardware.  Hardware commoditizes and in the eyes of the customer this should be a good thing.  The key to a VST strategy - just in case EMC is looking for some messaging as it ventures down the caching path - is flexibility.  It's a consumer (vs. vendor) driven model.  It would be a brave new world for EMC but, as we have said before, one that is deeply embedded in the NetApp DNA.  For more detail, on how Mercury plays a role in the VST strategy, give your NetApp sales team a call.  Chances are, they'll bring it up for you.

So, I put a few miles on over the past couple of months covering cities like Minneapolis and Des Moines - not a big stretch if you're based in Chicago - but throw a swing through Sydney, Brisbane and Melbourne and you can put an ass whooping on your circadian rhythms. (And as a Irish/Polish kid who did most of his growing up in Kentucky, I can tell you I pretty much have no rhythm).  Anyway, I had a chance to see a ton of customers and partners.  It wasn't uncommon to meet with 20 customers in the span of only a few days.  Let me tell you, the top 3 topics of interest in this order were: 1) Flash - particularly flash on host.  More on that later in the week.  2) Big Data - mammoth opportunity for e-Series and upcoming ONTAP functionality and, wait for it... 3) Backup.  Really?!  Backup?!  Yes, backup.  Virtualization got bumped.  Primarily because I think all the kids are doing it now.  It's in all the Sharper Image catalogs and in-flight magazines.  You're basically in the dark ages if you haven't virtualized something and called it a Cloud.


The not-so-dirty little secret: after 40 or so years, we're still struggling with how to efficiently back up all of the data we accumulate.  It's not that we haven't been able to get it right after all these years.  We're just saving a ton of data and it's outstripping our backup processes.  I have good fun with the backup architects when I'm out on the road.  It's one of the most critical jobs in the data center and yet when you ask the question, "who wants to be the backup guy?" it's funny to look out into the audience and see how many grown professionals who hate to make eye contact.  There's no hands rocketing in the air - oh, oh! Pick me! Pick me!  Heck no.  Think about it, every time your phone rings the person on the other end is already pissed off.  Nobody ever calls you to congratulate on another day of successful backups.  No, they've lost something and they want it back NOW!  This is usually accompanied by some explanation that sounds a lot like a storage gremlin: "It was here yesterday.  I don't know what happened but I came back to my desk and it was just gone!"  Well, at least they gave you an approximate time and rough description of the data abduction.  The flip side of this is when Exchange goes down and you get the call from a ViP who not only knows when it went down but who was standing next to them at the time; they live on their Blackberry/iPhone; they're on the road and when can they expect to have their mail access restore?  (Would that be the right time to let the ViP know that the recovery SLO for Exchange is two hours and they'll have to wait like everyone else?)  Out of all the war stories you can tell, I bet some of the best are around backup and recovery.  With the volume, richness and "everything is Tier 1" aspects of data, the backup challenge continues to expand disproportionately.


Enter the age of snapshots and replication.  I think it was last year when there was this absolutely insane discussion in the blogosphere on whether a snapshot constituted a backup.  I didn't pay too close attention to it.  It mainly sounded like one group of vendors with crappy snapshots telling another group of vendors with useful snapshots that they couldn't count snapshots as a backup.  Huh?!  The customers I talked to thought the whole discussion was goofy.  In general: if you could restore from it, it was a backup.  The rest of the discussion would focus on a complete data protection plan: how often to take a snapshot? Should you vault or replicate the snapshots to a separate site?   When and where can I roll to tape?  How can you factor in a disaster recovery plan? What's the restore process look like? (File that under backups are worthless; restores are priceless).  90% of your time is spent revising and refining the existing backup/restore process. 


With that as context for backup, I'd say the vast majority of the feedback I've heard from customers is, "NetApp - love your snapshots.  Love your replication.  Please don't make me jump to another tool."  The backup team has enough headaches managing the ever changing data landscape.  However slick you think your homegrown backup/replication tool is, at the end of the day it's yet another vendor tool, another set of instruction manuals, leather bound best practices, and requirements for a separate server (or VM).  Best case: this is seen as a necessary evil.  I know that's not part of any marketing campaign anywhere: "Come check out our solution. It sucks less than what you're doing now."  But, I think we've made some significant progress on flipping this around and turning it into a true positive.  The strategy is to simply melt into the background and let you use the tools you already have on the floor.  You've seen the work we've done with Syncsort and CommVault (SnapProtect)?  Allow me to introduce Symantec's Replication Director in NetBackup 7.5! This is a great next step in trying to keep the backup/recovery/DR process as simple as possible.  Under the covers, NetApp and Symantec worked together so that Replication Director can leverage our storage service APIs.  What this means to customers is you  will be able to schedule NetApp Snapshots, create SnapMirror and SnapVault relationships, integrate a tape backup schedule, have NetBackup index and catalog all of these backup images and never leave NetBackup!  You want to create a Storage Lifecycle Policy (SLP) that includes NetApp Snapshots, SnapVault and SnapMirror?  Go ahead!  Figure out how you many snapshots you want to retain, when you want to vault them, how to replicate for disaster recovery and assemble it all using Replication Director in NetBackup 7.5.  Our technology is still in there.  You just don't need to jump back and forth between screens to manually coordinate anything.  You can still take advantage of all of the the ONTAP efficiencies e.g. deduplication, compression.  (We've seen customer savings ranging from 20:1 to 50:1 to 70:1 on full backups).  You can still take advantage of Flexclones for test and development work, reporting, disaster recovery testing, off-site tape backup operations, etc. 


I know, "melting into the background" is not a headline grabber.  It's not as sexy as talking about virtualizing 5000 desktops and storing them all on the head of a pin.  I get that. But, at the end of the day, everyone has to talk to the backup guy.  Everything has to have a backup plan and the easier we can make it on the backup team to pull together that plan, the better off we all are.  That's why I do think that backup is still part of nearly every customer conversation I have.  That's why I do find myself getting some excitement going talking about this solution. I'd actually like to see the backup team go home at 5:00 o'clock and not have to come in on weekends.  A man can dream.

Price per GB.  It's basically a useless metric for comparison.  I get it - it sounds like a standard unit of measure but it's not.  It's insufficient and flawed.  Insufficient in that it focuses on one variable within one vector of a business (capex).  Flawed in that it assumes 1 EMC drive = 1 NetApp drive = 1 IBM drive = 1 HP drive and so on. 


Another way to get at this cost question is through the mountain of spreadsheets, papers, graphs on usable capacity.  Another useless metric.  Usually, it's one vendor doing the usable capacity calculation for their competition.  Really?  How do you think that's going to turn out?  Do you think EMC is going to march into your office and tell you that NetApp has the lowest price per GB in the industry?  Probably has the same chance that HP is going to slide a TCO report across the table that says "we're unbelievably expensive and a bear to manage."  Those TCO reports simply don't exist.  I defy you to go to any vendor's web site and find a crappy TCO report (to be specific, on them - not on a competitor).   I can see how some of this stuff can help support your decision but probably not make your decision.


So, what are you left with?  How do you compare things?  First, a prerequisites: it's fair to assume that different companies have different approaches to the same customer problem.  Second, let me do a couple things here: a) freak out the NetApp marketing department b) take the $/GB argument off the table.  For the sake of argument let's say that NetApp has the highest $/GB in the industry.  I'm sure our competitors are happy with the thought experiment at this point (and Chris Cummings just choked on his Stanford necktie) but, bear with me for  a minute.


Here's how I look at it: we get side-tracked with a flawed question.  The question is how much usable capacity can each vendor squeeze out of the same quantity of drives?  This is usually supported with some silly graphic (again, provided courtesy of your favorite competitor) of a single drive and a breakdown of the associated "overheads."   That would be great if all you were going to do is buy a single drive from each of us.  But, that's not the case.  The premise of the question is each vendor can do exactly the same thing with the same set of disks.  We all dedupe the same, snap the same, clone, thin provision, RAID protect, perform - all the same and, that's simply not true. 


Many NetApp innovations do not depend on thinking of something first.  It’s that we made features simple and practical to use in production: snapshots, RAID-DP, dedupe, non-dupe (cloning).  For example, in virtualized environments performance actually improves when you use our non-dupe technology.  NetApp has done an excellent job of leveraging existing WAFL constructs to deliver these features to the market.  My favorite story was, as a new hire, I asked Dave Hitz how he thought of snapshots.  Dave said he didn't really think of snapshots, they were already there.  (WAFL takes a consistency point at least every 10 seconds.  A snapshot is simply a consistency point that is retained under a unique name vs. letting it roll off with at the next CP).  If you understand NetApp snapshots, then you understand WAFL's ability to share 4K blocks.  If you understand WAFL block sharing, you understand how easy it is for us to implement dedupe and cloning. Most all of these efficiency features were "already there" and didn't exact a performance tax. We just had to leverage the WAFL DNA to bring them to market. 


Many competitors have the opposite problem: the DNA of their traditional storage systems didn't lend themselves well to these advanced features.  Most of these features became after-market bolt-ons.  When you’re dealing with a traditional storage approach, all of these feature bolt-ons come with a steep tax, which typically shows up in performance (revenue) and/or manageability (opex).  For traditional storage vendors, it's like trying to run a race with a weight vest on. Even some of the relatively new stuff out there takes a heck of a lot of gear to produce comparable results.  Take a look at the latest NetApp and Isilon SPECSFS benchmarks. Dimitris Krekoukias did a great job of breaking that down for us


The bottom line is it should show up on the bottom line.  There's a set goal by the customer represented by their performance, protection, flexibility and availability requirements.  It's not that vendors can't meet those requirements.  It's what they would have to bid in order to properly meet those requirements.  How many extra disks or SSD would have to be bid to compensate for performance hits due to snapshots?  Is everyone following their own best practices for tiering?  Do they have enough SSD included? Would they go with mirroring or some version of RAID-6?  If RAID-6, how would they compensatefor a RAID-6 performance tax.  What about dedupe and non-dupe capacity savings?  Would it even be recommended as a best practice?  Would it be implemented natively within the array or as a separate appliance?


You can continue to go down the list; separate the RFP technology from the practical technology.  In the final analysis if you're chipping away at a handful of percentages on single drives and calculating a price per GB then don't forget to add the traditional storage multiplier.  Typically, we're seeing anything from 2X - 3X: NetApp $/GB = 2($/GB) big 3-letter company. 

A little perspective and you realize FUD is so stupid.


As some of you know, I help coach (American) football here in Illinois: 7th and 8th grade boys in the Catholic Grade School Conference (CGSC). It's a travel program; highly competitive.  We just wrapped up an exciting year going 7-3.  There was a lot of emotion after our last game.  I've coached some of the boys for the past four years.  After that last game, I think it hit the team how close we had become and what a great experience the season had been.  The 8th graders were realizing that this was the last time they would wear their colors and, for the entire team, this was the last time we would take the field together as a unit, as a family.  Each year is special. The kids always teach me more about myself than I feel I teach them about the game of football.


As a coaching staff, we don't teach a win-at-all-costs attitude.  Yes, it's an "earned time" league (i.e. no minimum play-time rules) but, we talk about how to compete with honor; how to support your football brothers; the importance of off-field community contributions; grades; and respect for your family and respect for the other team. Don’t get me wrong, when we cross the white lines, our kids will compete hard and play to the echo of the whistle.  Often times, you'll hear a coach - a lot of coaches - characterize this as "playing with heart."  In an odd twist of fate, reality met the metaphor this year. 


Early in the season, coaches took notice of an outstanding 7th grade athlete - incredible balance, quickness and hands - and just a phenomenal attitude. Right away we had him slotted in as a running back and defensive back.  There were some struggles early on with conditioning but who doesn't have that at the beginning of the year?  As the season began to ramp, this young man still had some struggles – said he didn’t feel quite right - but we figured that he would round into shape soon and he certainly looked good when he was at full speed! 


So, one evening I show up to practice and there he is tossing the ball around with his teammates but he's not dressed for practice.  Just like any of the boys I asked him how he felt.  "Fine!  Feel great, Coach!  Wish I could play but I have to go in for heart surgery this Thursday!"  Whoa!  I didn’t expect to hear that!  You coach 13 and 14 year old boys long enough and you think you've heard just about every ache, pain, dog-ate-my-homework reason in the book.  "Coach, sorry I can't play.  I have heart surgery." was a new one on me.  It rocks you back.  It rocked the whole team back.


The young man did go through heart surgery early that Thursday morning.  He came through with flying colors!  It was a cardiac catheterization procedure where the doctors went in through an artery in his leg and one through his arm.  They fixed the heart defect and he was back at practice (in street clothes) two days later; returned to practice two weeks later; and played in a final scrimmage game at the end of the year.  How that young man faced this situation, the attitude that he had throughout, the fact that he came back to play a game - simple game - was inspirational to the team. 


In my mind, there was no doubt that this young man was blessed to have an amazing team of doctors: the knowledge, training, experience. Hard to imagine how one comfortably shoulders that type of responsibility as a doctor when you enter that operating room.  He also had an amazing family supporting him and quality teammates to cheer him on. In a supporting role was the technology: the catheter, the cameras, monitors, plastics, wires, computers, and, yes, storage.  It struck me: congrats to all involved.  It matters.


Please take a moment to reflect this holiday season and visit:


Formatted Text


There are no categories.