How do the flash solid state disk (SDD) strategies of EMC and Sun differ? EMC is super-charging its Symmetrix arrays with enterprise flash solid state drives (SSD). The idea is to have the most frequently accessed data reside in a tier zero of SSD storage with less frequently-accessed data in Fibre Channel hard disk drives (HDD …
Apples to Oranges
How can the author compare Sun to EMC, and how can the author compare in server SSD's to Array SSD's? Absolutely no comparison between technology and technology application.
Been there, done that, got the T-shirt
For a long time I had to buy SCSI disks because that was the kind that went with the battery backed write back cache SCSI RAID controllers from Adaptec and company.
These were always a bit of a headache to maintain.
On a software side we need to move towards event driven storage architectures where the user application is sent messages when various bits of data have been safely written to solid state cache, long term disk and replicated out to peers.
Then at a policy level you can choose which bits (literally) are so important that world and dog has to know about them before the local mutt can drop the bone and move on to the next scrap.
Storage subsystems have cacheing
Surely the big FC attached storage subsystems already have battery backed RAM for transactions going in, and pre-fetching for data coming out. I can't really see how Flash Memory will improve performance - perhaps it could provide a level 2 cache? Can't see what the benefit would be.
@AC - Apples to Oranges
Gotta agree with you as unless we've both missed the point entirely the SUN and EMC cache technologies are complementary, not competing with each other.
I don't understand why the author says Dell, HP and IBM can "combine the Sun and the EMC approaches" as if to say that a SUN server/EMC array combination is impossible... nonsense.
It doesn't have to be one vs the other
i.e. Think of a Sun server (with it's local SSD), connecting to an EMC SAN (with it's tiered flash/disk/etc storage).
Provides complimentary speedups at both layers, and should work well. :)
Does flash memory still have a limited number of write cycles?
When I last looked at Flash in detail, it had a limited lifetime - after a few hundred thousand write cycles to any given location, that location became unreliable. Techniques like "wear levelling" can be used so that there aren't any excessively used "hot spots" which wear out long before the rest of the chip, but there is still a finite (and not easily predictable) lifetime.
So what are Sun and EMC's plans to hide this from customers?
RE: Limited number of write cycles
Don't tell anyone, but disks had limited numbers of write cycles as well...
That should be Sun AND EMC - there's no reason for these to be thought of as competitive alternatives...except that EMC is shipping Flash drives already, while Sun has made more of a statement of direction.
A cached disk array already delivers I/O to servers much, much faster than disk drives alone can - and thus servers have already been "optimized" for faster-than-disk (and even faster-than-flash) I/O performance when dealing with SAN-based storage. And since RAM is still so much faster than NAND FLash, cached arrays still add significant benefit to I/O performance even for Flash-based storage.
As to how the inherent characteristics of NAND Flash are handled in the devices EMC is offering today, I've covered much of this in my blog:
Net-net: customers and applications simply treat the devices as they would any SAN-based disk storage - all the management is handled within the drive and with the cooperation/assistance of the storage operating system. NBD.
Unfortunately, as I pointed out in my blog yesterday none of the other vendors have come forward to explain their approaches yet.
They have no choice but to address these characteristics, but they've been mum on the details so far...
RE: @AC - Apples to Oranges
The point is HP and IBM make their own disk storage devices and servers, so they can develop in parallel as part of the usual internal interaction between product teams, whereas Sun will have to go out and work with an array partner (maybe several for different storage tiers) which means a slower process for each tier. Thus, Sun is shouting about in-server SSDs to try and obscure the fact that HP and IBM will probably get a bigger advantage out of the tech sooner than Sun. Likewise, EMC will probably produce a great solution at the storage end, but has to decide whether to go it alone and just do a storage solution or waste time working with many server vendors to get a solution that ties in with what could be several different server SSD implementation strategies, possibly letting HP and IBM steal a march and get to market first.
Not so sure about the need for end-to-end integration
The implication that the "best" flash solution requires end-to-end integration of servers and storage has yet to be proven. Especially since storage arrays today are capable of delivering performance that is better than what even server-embedded flash can deliver.
And while performance is one benefit that drives demand for external storage, it's not the only one, nor necessarily the most important one. Consolidation, resource sharing, multi-platform/multi-application replication consistency, back-up offloading, parallel development using snapshots of "live" data, thin provisioning, data mobility are among other reasons people use enternal storage. Many of these cannot be adequately addressed by embedded storage approaches.
I suspect the end-game will look more like it does today than anything radically integrated - with flash playing a role on both sides of the SAN links. And if there does come some neat new way of leveraging Flash that requires cooperation between the host and the storage, inevitably customers will demand it be implemented using well-defined standards so as to avoid any threat of end-to-end vendor lock-in.
Re: Storage systems have caching
Yes, they do, but they are still limited by the number of physical I/Os that the hard disk can handle. Lets say there is an 80% cache hit rate, that means 20% of I/Os have to be satisfied from the hard disks. Now assume 20 drives each capable of 300 IOPs, that 20% can't exceed 6000 IOPs, so overall throughput in real world applications is going to peak at around 30K IOPs, regardless of hw fast the cache is.
If you replace those twenty drives with 10 SSDs each capable of 1000 IOPs and you've got 10,000 IOPs from disk, or 50,000 IOPs overall.
SSD is inevitable, and will ultimately kill what we think of as high performance drives (i.e. 15K RPM FC drives)