NetApp - The Missing Shade of Blue

An HP LeftHand Duplication Calculator

Our industry drives towards greater and greater storage efficiency. Green IT was the buzz in the media for a while, and although it's not getting the column inches it got last year, being efficient hasn't gone away as a business requirement.

It's a maturation effect; once the message is clear, media and CIO attention turns to other things, and the expectation is that the IT industry will get on with it and solve the problem. The storage industry has (with exceptions) risen to the challenge, with thin provisioning, virtualization of storage, larger and more energy efficient drives, and so on. Choosing the right storage system can make big savings.

• Smaller physical footprint
• Lower power and cooling
• Cheaper to buy and maintain

The list goes on. Deduplication on primary storage is the latest, and possibly greatest, contribution to really wringing every drop of space out of your storage system. Surprisingly (to me at any rate) some of these cost-saving measures have improved performance too. For example, deduplication and caching together works just as well on cheaper, slower and cooler disks as it does on expensive, hot and fast disks.

There are a number of efficiency calculators for primary storage out on the intertubes at the moment; one from NetApp, and one from EMC for NAS only -- which was originally entitled EMC Celerra Data Duplication. Although the title has been corrected, it still delivers the same poor results as before.

Leaving that aside for the moment, what the NetApp's calculator demonstrates quite clearly is that it's possible to store more data, more efficiently than ever before. Some in the storage industry don't appear to have got the message though.

HP's LeftHand.

I was confused by a video from Chris McCall, ex LeftHand Networks and now at HP. Two points about his video struck me as a little out of kilter in his positioning of LeftHand inside HP. LHN is now part of an HP "Unified Storage" division. Hold up! Unified? The "HP LeftHand P4000 SAN" is an iSCSI SAN system only. Doesn't sound terribly unified to me.

But the claim that really had me scratching my noddle was the claim that the LHN solution meets the needs of Green IT.

LHN uses something called network RAID over the top of storage nodes; they're HP servers running RAID5. Network RAID is nothing more than a fancy term for RAID5 synchronous mirroring, something that an LHN cluster needs to do because the individual storage nodes are SPOFs -- single points of failure. So copies of data on other nodes is essential if you ever expect to see your data again.

Let's cut to the chase. Here's the HP LeftHand Duplication Calculator. Unlike NetApp's space efficiency calculator, the LHN Duplication Calculator I've designed doesn't have any input fields or buttons. That's because, regardless of how small or how large your LHN SAN, it's always...

 

35% usable

Buy 10TB, get to use 3.5TB. That's about double the raw storage you'd need to buy from NetApp. No deduplication on an LHN system either, so you'll need to buy even more from HP.

LHN means more space, more power, more cooling, more cost per usable TB. Tell me, how can HP claim that this is green? 

.

[Updated 24June2009: corrected Chris McCall of HP's name]

WALL·E, It's Time To Dump EVA

I'm a big fan of Pixar, and I loved WALL·E. I even went and bought the DVD, I'm that smitten by this work of genius.

Here's the challenge that Pixar rose to, and that I think summarises the greatness of this film; it's a cartoon about WALL·E, a robot that falls in love with another robot, EVA. Yes, I'm a child when it comes to this kind of stuff, but that's some trick Pixar pull off. Reality twice removed; a cartoon about robots and love. Brilliant.

I can't love HP's EVA though. And I don't think I'm going to like the latest EVAs either. When they arrive, that is.

For months I've been hearing about the next range of HP EVA StorageWorks systems. Last year, the EVA4400 replaced the EVA4100. Then the EVA6400 and EVA8400 were supposed to replace the EVA6100 and EVA8100 respectively.

"So where does this leave the EVA6100?" asks Chet Jacobs, way back in April 2008.

It's a good question, and if anyone should know, he should; he's Chief StorageWorks Evangelist at HP. 2H2008 has come and gone, and there's been nothing about the missing boxes since then.

Can we expect a launch of an extension to the EVA range any day soon now? Probably, but I think you'll have to wait until March 10th.

So if you're a customer of HP and you're about to buy in to the HP vision of storage with an EVAx100 system (something I wouldn't recommend, but you know that already), I'd be looking to ask a lot of hard questions of your HP and HP channel sales people.

Like; So where does this leave me when I buy an EVA6100 or EVA8100?

• Is it field upgradable at no expense to me when the new model comes out? Will I have to take an outage to do the upgrade?
• What kind of performance improvement does the new range offer?
• What kind of huge discount do I get for buying yesterday's tin?
• Am I still stuck with FC connectivity only? No iSCSI? No dedupe? No NAS? No smarts at all? Are you guys kidding?

Don't be a wally (in the British sense). HP are no Pixar, and it's time to end the love affair. Dump the EVA now.

.

Finding a Pair of Socks

One of the common pieces of FUD (Fear Uncertainty and Doubt) that gets sent by colleagues to my inbox at ShadeOfBlue Towers is that everyone is saying NetApp FAS systems get slower as they fill up.

Some vendors have even taken to pointing our customers to this NetApp document as proof. Help me! Is it true?

Here’s a graph from the paper. (A point here; read the full paper for the details, but the lines to look at are the blue to 50%, followed by the green from 50% to 100%. And take a look at Kostadis’ blog for more detail on our WAFL technology.)

Look at the equivalently spec’ed EMC system below the NetApp line. Go ask other vendors for their graphs of performance at specific capacity points too; I suspect the silence will be deafening, or you might get lucky and get back a remarkably similar chart.

Is the FUD point made? No, because every storage system gets slower as it fills up. And some just start bad, and then get worse.

So why does increasing capacity utilization affect performance? Here’s an analogy; it’s like me trying to find a decent pair of matching socks (preferably without holes) in my sock drawer. The more socks, the longer it takes me to find just the right pair.

But with something that understood my sock needs, it needn’t take quite as long. So how do we make sure that performance stays high as the system fills? We’ve worked hard on this problem, and we’ve got some cool technology that helps.

Here’s one; the NetApp Sock Handler.

Readsets

Prefetching sounds pretty easy. For instance, in a file based NAS system (if it’s smart enough), when you start reading a file, the likelihood is that you want to read all of it.

For block based though, the read patterns can’t be ascertained the same way, as there’s no semantic information as in the file case that can help with the prefetch pattern.

For all read operations, large amounts of cache is employed in a NetApp system for staging pre-fetched data. We uses an adaptive read history logging system based on “readsets,” which provide much better performance than traditional and fixed read-ahead schemes.

In fact, multiple readsets, can support caching for individual files (for NAS) or LUNs (for SAN), which means that multiple read streams can be pre-fetched simultaneously. The number of readsets per file or LUN object is related to the frequency of access and the size of the object.

The system can adaptively select an optimized read-ahead size for each read stream based on historical factors, such as

• the number of read requests processed in the read stream
• the amount of host-requested data in the read stream
• a read access style associated with the read stream
• forward and backward reading
• identifying coalesced and fuzzy sequences of arbitrary read access patterns

Cache management is helped by algorithms that determine when to perform read-ahead operations, and how long each read stream's data should be retained in cache.

Readsets are just one of the technologies that ensures NetApp systems stay as fast as possible as the system fills.

It doesn’t help with my sock drawer, unfortunately, but it might beat the FUD off.

.

ELF, Wealth and Happiness

Usable Capacity

How to describe capacity? I’ve been exploring the whole usable capacity argument in my last few blog entries. There’s one thing for sure; we're in desperate need of new words and phrases to describe new technologies. Of specific interest to me are the inadequate words

usable capacity or capacity utilization

I consider those to be describing (albeit unclearly) the same thing. Two recent examples come to mind.

How Long is a Space Walk?

Part 1 Three Men Make a Tiger
Part 2 Space is Mind Bogglingly Big
Part 3 Think Tesseract; More Space Than A Cube
Part 4 Micrometer, Crayon, Ax

Most Sunday mornings, Carol and I take a walk down to a local coffee shop, buy a newspaper and spend a little time catching up on the week’s news. This Sunday’s big headline (apart from the collapse of Western civilization as we know it) was Zhai Zhigang’s space walk and the successful return to Earth of the three Chinese taikonauts this weekend.

In the sidebar of the article I spot some other space walk facts. The longest space walk was by US astronaut Susan Helms, at 8 hours and 56 minutes, which beats the Chinese effort (impressive though it is) into a cocked hat. Zhai was out of the capsule for only 15 minutes..

“Amazing” says I to Carol, having caught her attention. “How long do you think the longest space walk was?”.

“Let me guess”, she says. “About a mile?”