New Fusion ioDrive2 and ioDrive2 Duo

re: New Fusion ioDrive2 and ioDrive2 Duo

Adam Machanic — Tue, 04 Oct 2011 23:16:15 GMT

"at some conference of no importance."

Love it :-)

re: New Fusion ioDrive2 and ioDrive2 Duo

Oliver Aaltonen — Wed, 05 Oct 2011 15:58:54 GMT

For what it's worth, we've deployed ~100 of the first-generation ioDrive and ioDrive Duos for our customers' database servers (running RHEL, but the hardware's the same), and we have yet to see a single failure in well over a year of production use.

I can recall only two instances where the ioDrives acted funky, and both were on systems with known PCIe issues at the hardware level (i.e. bad riser, motherboard, and/or firmware). The ioDrives disappeared after a reboot, and never re-appeared. I've never seen them fail on a system that's up and running.

re: New Fusion ioDrive2 and ioDrive2 Duo

jchang — Wed, 05 Oct 2011 16:26:04 GMT

Adam: well perhaps of some interest as they do have that iron man impersonator

Oliver: yes this help alot. There are 365.2425 x 24 = 8765.82 hours per year. For 1M-hr MTBF, we should expect 9 failures per 1000 units each year. Please let us know if this is still the case next year too!

The reason we have RAID is that in the old days, HDD MTBF was more like 100K-hr, so a storage system with 1000 drives would encounter 100 failures per year, ie, not good. If we do have solid evidence for Fusion at 1M-hr MTBF (actual production, not elevated temperature testing) this means a system with 10 ioDrives has a 1 out of 10 expectation of failure in one year of operation, which should be sufficient to support the no-RAID proposal.

Furthermore, I am guessing that the most likely mode of SSD failure is inability to write new data, but old data is still readable (near). Wouldn't it be a neat trick if SQL Server could detect that one SSD has write-failed, and just write changes to other working units? and then migrate data off the failed SSD

re: New Fusion ioDrive2 and ioDrive2 Duo

Adam Machanic — Wed, 05 Oct 2011 16:55:14 GMT

BTW, in my current project we have two servers, each with 7 Fusion-IO cards. In one of the servers a couple of months ago we had 3 drives totally fail in a two week period. Not sure if it was a bad batch, or what. I'm still a big fan of the cards.

re: New Fusion ioDrive2 and ioDrive2 Duo

jchang — Wed, 05 Oct 2011 20:34:51 GMT

I have heard of multiple disks failing simultaneously, which would lead me to believe that was due to environmental factors - under-voltage, failed fanned etc. The MTBF stuff I talked about should apply to statistical failure rate. For 3 units in a 2 week period, I am inclined to suggest a bad component, a capacitor perhaps? Still thats a good point. RAID is only a good solution for statistical failure events, such that 2 or 3 disks failing nearly simultaneously (a second unit fails before the spare is put in and the RAID rebuilt) does not happen. For systemic failure events, I think it is better to rely on a failover system with its own storage (ie, not a cluster). Given that there are two complete systems for failover, there should be no need to go overboard on single HA.

re: New Fusion ioDrive2 and ioDrive2 Duo

Dave Wujcik — Thu, 06 Oct 2011 16:39:20 GMT

This is a cost-effective, fast, reliable solution to accelerating high IO loads such as database/VDI, vs having to use hundreds of spinning disks to try and keep up with the same performance. You can raid all the SSDs you want, you'll never get sub 50us latencies out of it, or any reliability. The low latency is really what makes the product.

-- Dave

re: New Fusion ioDrive2 and ioDrive2 Duo

jchang — Thu, 06 Oct 2011 19:13:11 GMT

Most RDMBS engines, even the one from Ironman, have from the beginning been properly optimized for very large HDD arrays, so that properly written code is not hindered in performance. Of course, crappy code always performs like crap.

See my summary of TPC-E benchmark results, which shows that SSD may improve performance in the range of 2-10% depending on memory (a larger impact for memory constrained, less for 1TB memory). The theory is that with SSDs, disk latency is lower, and there are fewer transactions in flight at any given point in time, which improves efficiency.

The advantage of SSDs is that unconstrained performance can now be achieved a much lower cost point. An unconstrained HDD system might have 500 disks. For 15K 146GB SAS direct-attach, figure $500 per disk amortizing the disk enclosure, so $250K, with a raw capacity of 73TB, or RAID 10 capacity of 36TB.

Now compare consumer and enterprise SSD at $4K and $15K per TB respectively. If we really need 36TB net capacity, then the HDD solution is good. But if we only 1-10TB, then the SSD solution is better.

re: New Fusion ioDrive2 and ioDrive2 Duo

Robert (Bob) Leithiser — Sun, 30 Oct 2011 04:04:49 GMT

An item of major significance is that devices at this level of write latency introduce a new paradigm for data mining. Whereas the model to date for data mining has been aggregating large amounts of data and then looking for patterns, the design pattern is transformed by the amazing write latencies of these devices. Now, instead of generating aggregates and analytical derivative values in batch, the fast write latencies allow the immediate storage of the calculated data.

I've written some complex triggers that leverage the low latency of PCIE-SSD to do expensive calculations including rolling 20 day Bollinger Band and moving averages as quote data is received. These are plenty fast enough to keep up with 20 Mbps Internet pipes used to collect the raw data. Such a technique can support contrarian financial trading bots that anticipate market reversals before they start by integrating real-time quote data with longer-term trends and correlations. This type of real-time monitoring is potentially more profitable and less risky than simply riding trends as do most of the current trading bots.

I believe that a key to proactive BI which includes decision-making with simulative validation rather than just decision-analysis is in frameworks that continually aggregate derivatives associated with event sequences. If you maintain sufficient analytics in real-time relative to the data collection then the relational state changes between significant events can be monitored constantly to allow actionable BI that adapts decision criteria dynamically without the need for post-mortem analysis of correlative data that is prone to be out of date by the time it is analyzed.

Something to think about…