Solid State Disk (SSD)
So EMC announced SSD on DMX last week. I have had a few press interviews recently and of course I get asked about Pillar’s position or my thoughts on the announcement in general.
For some applications, some SSD attached to an array is a good deal albeit expensive. Certainly one can get a ton of IOPS at low latency from solid state memory versus hard disk drives with their moving parts. Eventually, when solid state memory prices get low enough and write-cycle limitations are overcome, it will be nice to replace disk drives that vibrate, make funny noises, and throw an occasional piston rod through the ceiling. Indeed, Laptops are already being sold using SSD instead of hard disk drives.
The important thing to keep in mind is that storage arrays were not designed to fully leverage Solid State Disk; today’s array architectures from any vendor will quickly become the bottleneck for too much SSD. Why? The reason is because the bandwidth and latency of SSD are so much different than that of hard disk as to quickly surpass that of the controller that it is attached to. Furthermore, heavy access of the SSD on the array will overshadow the disk that is on it – you can look at it as though SSD can quickly consume much of the array resources. Pillar’s QoS will somewhat alleviate this problem, but at the expense of not fully leveraging the SSD you have in the Pillar storage pool.
In some ways Solid State Disk reminds me of VTL. VTL is Virtual Tape – making a faster lower latency technology substitute for tape, but retain the way systems perceive the storage - as tape. In other words, we are taking a great technology with lots of advantages and hiding it under the guise of one that is slower and clunkier – all to keep from having to redesign the way we use “tape”. Solid State Memory under the guise that it is disk is no different. There are a lot more efficient ways to use solid state memory other than making it appear as though it is disk!
That being said, both SSD and VTL allow the IT community to bridge between existing huge infrastructures (for disk array and tape respectively) and the ultimate best realization of the technologies we can build.
Oh – and Pillar’s position includes SSD on our Axiom Storage Array. With QoS, the customers will be able to provision LUNS and Filesystems at Hyperdrive speeds when they have SSD resources in the storage pool.
North America

May be an interesting solution later down the road when 128GB SSD wont cost over $1000 a pop.
What about SAS disks in Axiom systems? SAS disks may come down sooner in price with higher speeds than the normal 7200rpm of standard SATA.
Seems the consumer market tests out the newer tech before it makes it up to enterprise where stability is key.
Posted by: Kunal Patel | February 04, 2008 at 11:19 AM
Kunal -
Thanks for the comment. The thing that bugs me most about SSD is that it is probably best attached directly for low latency. Going through shared storage disk seems to defeat the speed aspect a bit. I imagine that there are a few really good apps that could use it in a shared network.
See the November 28th 2007 post if you want to read a bit about our SSA directions.
Any other questions - please ask! Thanks
Mike
Posted by: Mike Workman | February 23, 2008 at 03:38 PM
As a "time-served" sys-prog, I have had many conversations with client saying much the same, in the light of this we have been developing over the last few years the "dataslide" concept which is designed to provide a RAM architecture in an NV structure, particularly DB friendly as a 2D basis format.
Posted by: Charles F J Barnes | May 12, 2008 at 03:55 AM