« IT Is Inherently Green | Main | Updates To The Capacity Post »

August 28, 2008

Comments

Andy Barclay

"And for NAS, we are leaning to a V3170 in front of a CX4. So you both win ;-)"

Posted by: Martin G | August 29, 2008 at 01:32 PM

Doesn't this type of feedback from an end user tell you something here?

The virtualisation of a CX4 by a V3170 delivering a NAS solution indicates that the customer is not happy with the features supplied on one vendors storage system - so much so they feel the need for it to virtualized it behind another vendor’s appliance.

This type of feedback on an EMC blog by an end user is amusing and I am surprised no one else has capitalized on this comment... yet.

The cost of hardware in this case raw disk is relatively cheap. The features the vendor delivers using the hardware is what you really have to pay for when you buy a storage system.

So in answer to your statement "Your Usable Capacity May Vary" - my reply as an end user would be "Who cares, as long as I get the features I want out of the storage system together with the reliability and performance I expect from an enterprise class storage system.

The three vendors you have picked on in this blog are quite interesting. Two of the three have evolved originally from being hardware based and the other software. After all features are predominantly derived from software-based manipulation of hardware.


It looks to me that the two companies with hardware roots are playing catch up and one of them is using discussions such as this to mask their deficiencies in other areas where they are not measuring up!

I think you should be asking – what does the customer really want? What is important?

Maybe if you identified what people want from technology (in your case it would be a spell checker - your blog states that you enjoy “piano, mountain bking and skiing-- in that order.”) then we would be having a more interesting discussion about what each vendor delivers in the way of features.

I suppose your response to my feedback will be “On yer bke” and my response would be “F7 to you” :o)

Nice discussion btw... but it's just not about what I think the end user is interested in.

- Andy

Martin G

I really care about useable capacity as an end-user; I may be in the position where I have to put somewhere between 18-50 petabytes of storage on the floor over the next three years. Okay, this is an extreme example but if my overhead is too high; I'm going to have build new data centres.

I want my storage to be as efficient as possible; I also want it to have a layered feature set, so that I can turn on the features I need but also have options to turn off those features I don't need. And a whole new subject, I only want to pay for the features I use on the disk I'm using i.e I don't want to pay for software on a per head/controller basis!

Daniell

Man....I SO want to get in on this.
But I got a bad cold and my head is not working properly.
However, I would like to say it IS a good discussion regardless of one might think of the results EMC got.

But, there is also the thing that it is perhaps looked on a little to narrow as Exchange is (also) about supporting X users/mailboxes with a reasonable responsetime (20ms max as per MS) etc.
Hence a discussion about performance and disk efficiency is very much valid.

Maybe as a follow on to your test?
Once you have made the calculations, set it up as the best practices says; run Jetstress.

That way we will see if being most efficient in the amount of disks needed to reach a certain usable capacity is the same as being able to sustain most users/mailboxes.


Regards,
Daniell

Shaun

I thought EMC's recommendation was to use raid 1/0 for Exchange?

John Ashton

Hopefully the information will be updated soon. After all as Chuck pointed out:

We didn't try to game this. We didn’t need to.

yfeefy

I've read the comments so far, and it is an interesting discussion.

I'm an end user helping to manage four EVA units, they are all maxed out at 240 drives, and there are no doubt more on the way. It's kind of an understandable newbie mistake to configure too many disk groups. You lose usual capacity, and subvert the self-balancing capability of the array that way. We made too many (six total, but now reduced to four) on our first array, You can mostly get around the balance problem if you then manually balance your IOPS workload across the disk groups, but why do that if the array will do it naturally?

What you do lose with the very large disk groups is the potential size of a data-loss event -- The EVA has an unusual implementation of RAID, data is protected within RAID groups of 6-11 drives called RSSes. If you simultaneously fail two drives in an RSS you will lose every vraid5 vdisks in the disk group. The probability of lightning striking twice like this, however is very low, since in a large disk group there will be many RSSes. This is improved further by failure prediction which moves data off a suspect drive and ungroups it automatically. For vraid1 vdisks to fail, you have to lose a disk and it's 'married pair disk' within an RSS simultaneously (joint probability should be n*(n-1) drives in group). After understanding this we've moved to fewer larger groups.

The poster who says a vdisk provides performance isolation isn't really correct, that's also mostly provided by separate diskgroups - not only physical disks but also cache management is somewhat isolated (although details are sketchy there). But 'performance isolation' is overrated - the way to get the best total performance possible from the hardware is to stripe every lun across every drive.
One can still isolate 'problem' apps with a few disk groups,


All arrays share resources, so absolute performance isolation is impossible within an array. If you really have an app that has to have a guaranteed service level, maybe it should have dedicated hardware.

yfeefy

I also disagree with the poster who said disk is cheap - it usually is the top line item by a significant margin. Sure, it's a lot cheaper than it used to be, but we're all using so damn much of it.

Jim McNulty

Coming from an EVA environment I can say that your assessment is good overall. Although HP does recommend fewer storage groups, in practicality this proves problematic. I had storage groups for FC disk and FATA, which each placed a large number of spindles in each. If ALL the array did was backend exchange it would have been fine but in a mixed use scenario, as was our case, we found this recommendation troublesome. With singular large storage groups and several multi-purpose hosts attached you now have the potential for a single host to affect the performance of the entire storage group. We had numerous *whole* array outages with no clear cause, but tracing through events in the time line pointed to probable suspects. To avoid this you would *have* to break out the SGs as Chuck indicated, but if performance and reliability aren't a concern for you...

Chuck maybe you could adjust your EVA numbers for the (albeit problematic) recommendation of 1-2 storage groups? That will help the HP numbers a bit but not much. That recommendation should be seriously caveated but HP!

yfeefy

Jim, I'm not sure your whole array outages would have been helped at all by having more disk groups.
I do feel the EVA used to be rather unreliable, and we a few outages here, probably similar to what you had. The eva had to be rebooted in this instance, but we never lost any data. The cause of these were
failing disk interfaces continually blathering on the backend, saturating it with numerous loop events.

Knock wood, there have been no such outages for quite a while since the firmware on the drives were updated (several other changes were made to deal with this specific issue).

As a customer we indicated to the vendor our fury about this problem, and would not have continued with this array had we felt they had not been addressed. I'm glad it has been, because the EVA is a joy to use and manage, in my opinion.

You mention performance and availability. Even though hosts using vdisks in the same disk group share physical disks, a large disk group can handle a LOT of IOPS. That's your best total perfoamcne option. You may want to isolate a host doing a lot of I/O, but by moving it to a separate smaller disk group, will you be limiting performance of the host that really needs it? That's the sysadmin's call, and this is one of the subtle parts of eva management, but in practice the complexity is much less because most hosts will not be a problem, unless you've underconfigured your storage. The best practice config generally "just works", and to improve eva performacne -- add more disks.

Brandon

I don't care to get drawn into a political discussion regarding EMC vs Netapp vs HP. However, I would like to point out that you should remove the "aggregate snap reserve" from your Netapp calculations. Aggregate snap reserve is only used in deployments with synchronous mirroring. In the type of deployment you are discussing, you would lose nothing to aggregate snap reserve.

Matthew Ayaz

Hi Chuck...
I'm alot confused...
I'm working on my assignment n i need ur help...
I need to ask some questions...
What are storage devices in a computer?
What are their roles in a computer?
What are different types of Storage Devices?
How do you measure their capacity?
Can you please List at least five different types of storage devices?
At least one Brand of Each device along its price........?

Thnxx...

Chuck Hollis


Tell me more about this homework assignment?

-- Chuck

AM Tang

Chuck,

How do current PCIe cards (such as Fusion IO's ioDrive Octal and Violin Memory's Velocity) stack up in comparison to HDDs and SSDs?

Thanks and great article.

T2

The comments to this entry are closed.

Chuck Hollis


  • Chuck Hollis
    SVP, Oracle Converged Infrastructure Systems
    @chuckhollis

    Chuck now works for Oracle, and is now deeply embroiled in IT infrastructure.

    Previously, he was with VMware for 2 years, and EMC for 18 years before that, most of them great.

    He enjoys speaking to customer and industry audiences about a variety of technology topics, and -- of course -- enjoys blogging.

    Chuck lives in Vero Beach, FL with his wife and four dogs when he's not traveling. In his spare time, Chuck is working on his second career as an aging rock musician.

    Warning: do not ever buy him a drink when there is a piano nearby.

    Note: these are my personal views, and aren't reviewed or approved by my employer.
Enter your Email:
Preview | Powered by FeedBlitz

General Housekeeping

  • Frequency of Updates
    I try and write something new 1-2 times per week; less if I'm travelling, more if I'm in the office. Hopefully you'll find the frequency about right!
  • Comments and Feedback
    All courteous comments welcome. TypePad occasionally puts comments into the spam folder, but I'll fish them out. Thanks!