http://media.netapp.com/documents/rp-0046.pdf

Lot’s of talk about the dreaded double disk drive failure as it is the perceived soft underbelly of the XIV system. But doesn’t RAID5 in a VP Pool on DMX pose just as much of an availability hazard? Doesn’t the same apply to an HDP Pool with RAID5 on a USP-V? Yes, I would argue that FC or SATA in the same wide striped pools with RAID5 protection have close to the same probabilities for data loss.

Jesse you said above, “I’d feel 100% better about it if lost blocks could be recalled from the remote mirror like the Symm does”, I’ll have to ask somebody from IBM again just to verify but I’m pretty sure XIV does this now with both it’s sync and async solutions. In fact, there is zero intervention required to pull the 3rd or 4th copies of data from the remote target systems. So maybe losing data on a replicated XIV system is like winning Powerball 3 times consecutively

Next thing to consider that the guys from XIV shared with me, the double disk drive failure only pertains to hard disk errors – it doesn’t apply to proactive disks sparing that are sparked from Latent Defects or Disk Scrubbing. Hard errors only account for 7% of all replaced disks in the system (XIV numbers) and 93% are proactively spared. These numbers gel with stats I got from HDS when I was working with the USP-V and AMS. I’m guessing they would gel with EMC numbers too. Also, when a disk is proactively spared a third copy of data is created on the XIV frame before the spare process kicks off.

Does this mean that data loss event has a zero probability? Certainly not! This will never be zero. I just don’t buy all FUD talk. Every product on the market has value and merit and it’s an exposed and scared manufacturer that puts out FUD on its competition rather than brag on its own product. IMHO

Anyway. I’m looking forward to see if anybody will post performance numbers seen in the field. I’ve heard numbers range from 20k IOPS to 100k IOPS workload dependent – anybody else heard anything on real world performance?

The one we got about…what…4 months ago? Still doesn’t have data on it. The one at the DR site still isn’t even connected to the SAN (it is however plugged in, sucking up power and throwing off HEAT)

I haven’t been privy to why…but I suspect none of the internal customers want to risk their data on it.

Bottom line. The *ONLY* way an inferior product can compete is based on price. And anything that is psychotically underpriced like that either has major hidden costs you’ll run into down the road, or it’s crap.

Without exception.

Point is when a 1TB disk has failed – that is still 1TB of data that is now single copy only in the array.

Break that into 1MB chunks fair enough. But we now have 1 million chunks to restore and 179-12(module) disks involved so 167 disks busy with parallel rebuilds – that is why it takes less time – but it is also 167 times more likely to fail during that period – probability theory indicates possibly even higher chance than a single disk failing in 167x 30 min ie 83.5 hours or three and a half days!!!

And what really scares me is this magic list you get of which chunks were not recovered after a second disk failure – somebody in systems admin is going to run around WHILE THEIR APPLICATIONS ARE LIVE working out which files have holes in them ?????

Beam me up Scotty!

* Competetors who don’t have a simliar product.

* People who don’t know how to use it or how it works.

For the rest of us it’s a lifesaver esp when you consider that “Synchronous Replication Range” is usually shorter than “Minimum Safe Distance”

Tony –

Read the article you referenced in your reply, and you do make some interesting points.

With the “wide-stripe” you MIGHT lose about 9.1G of data in the event of a dual-disk failure. (The MIGHT of course referring to how far you are through the rebuild when the second disk fails)

That’s not bad, depending on WHICH 9.1G you lose. If you’re running straight filesystems you might lose file-pointers and file-data, as you say, no big deal. You restore the affected files.

However, if you are running LVM and lose parts of a logical volume, or the journal, it’s not as likely to recover as easily. It’s *MORE* likely you’d have to replace a whole filesystem. (As is the case when you lose one drive out of a striped volume group, *ALL* of the LV’s are lost because there is no longer a consistency point with which to reference data.

And if you happen to lose the block containing the part of the inode table for a filesystem, you’re even more dead in the water, whole filesystem is irrecoverable.

In any case, I notice you carefully use the words “has never happened in the field.” This leads me to believe you’ve been able to replicate it in the lab. This also leads me to believe that you are fully aware that the odds of such a failure are not non-zero.

And yes, with Raid-1,3,5, etc. A dual-disk failure is just as much a risk. It’s why for criticial, non-performance data I will always go with Raid-6 on Clariion. Raid-level on Symmetrix with Sync replication is irrelevant to protection levels. You’d have to lose the right two disks on two geographically dispersed frames at the same time to lose data. And while the odds of this happening are not zero, you are more likely to win the power-ball jackpot in five consecutive drawings.

I agree, the quick recovery is nice, and does limit your exposure. I’d feel 100% better about it if lost blocks could be recalled from the remote mirror like the Symm does. (A Symmetrix with SRDF/S can lose an entire raid-group on the source side and will continue to service IO, albeit slowly, from the target Symm.)

Again – I’m intregued… Hopefully I’ll get to see it work and put it through it’s paces. More than likely though the IBM zealots won’t let me near it.

Sokay though, I’m going to have my hands full with the new DMX4 and the 300+TB of new Clariion storage that’s on it’s way.

I’m not arguing that it’s useless, I see it as a great fit for the archival market, mostly the same market that I see Atmos going into, but Atmos also has the global namespace and more options for data-concurrency.

I would love it however if you’d clarify the performance numbers for the XiV. From what I’ve read, the throughput for the entire box is put at 25,000-ish IOPS, real-world experience puts the DMX-4 as able to do that on one processor pair.

Since the XiV has never, to my knowledge, been tested by a reputable third-party even my 25,000 number is suspect (since it did, point of fact, come from someone @ EMC)

It’s my opinion that the only reason NOT to have Gartner or some third party firm put a machine through it’s paces is if there is something to hide. (25k IOPS coming from a cached disk array would definitely qualify)

On that note, what does the performance drop to when the box hits the ~75% capacity mark when all IO goes THROUGH the access nodes straight to the data-nodes, and yes, I understand that data is going from HBA –> Cache –> Cache –> Disk, but when the link between the access node and the data node is Gigabit Ethernet, that is a pretty significant bottleneck.

I understand – it’s your job to defend your product, and you will do so vigorously. I can’t fault you for that, your paycheck has the IBM logo on it. (And yes, indirectly, EMC pays mine, so we’re even)

However it’s not in my job description to defend EMC, I do it because I love their products. (as I’ve said before, I personally have a clariion in my basement) – I’ve STILL yet to find a storage system superior to the DMX. In speed, or resilience. (yeah, it doesn’t have that Macintosh like GUI to manage it with.)

That and, for the most part, I don’t trust people, especially sales and marketing people. So as I’ve also said. Tell IBM to put me in front of one and let me bang on it, if I learn differently I’ll be the first one to admit I am wrong, publicly. (you and I both know THAT isn’t going to happen)

If I see I am wrong, I will admit I’m wrong, but only then.

Oh, and if ambient air temperature hits 66C and my system hasn’t shut itself down there is something wrong. The idea is to shut down automatically to protect against damage, and more importantly, data loss – if it doesn’t shut down, it’s putting my data at risk, which is unforgivable.

Also, my math puts, worst-case-scenario, a CX4-960 with 180 drives (closest to similarly configured XIV) at about 64 watts per usable terabyte, under heaviest load. (All DAE power supplies maxed out, which never happens) And that’s just Raid-1, Raid-5 is 40.4 watts per usable terabyte. But you can’t do raid-5, right?

And THAT is just the 1TB full-power drives, the 1 and 2TB low-power drives are 33% lower power consumption. (And sitting at idle the numbers are about half that.)

Look forward to your response.

To address the double-drive failure non-issue FUD, see my post here:

https://www.ibm.com/developerworks/mydeveloperworks/blogs/InsideSystemStorage/entry/ddf-debunked-xiv-two-years-later?lang=en

I suggest you compare energy figures in Watts per Usable TB. The XIV with 1TB drives is only 97 W/TB, and with 2TB drives is only 41 W/TB. These numbers are in the XIV Introduction and Planning Guide if you need to review them in more detail. Compare that to Solid-State Drives (120 W/TB) and traditional disk systems with FC drives (380 to 435 W/TB) and you see that XIV is very GREEN storage.

One of our clients lost their CRAC causing the entire data center to go to 66 Celcius, and the only system to keep running was their XIV.

— Tony