So what's Intel been doing with NAND based Solid State Disk (SSDs) since my blog on our next generation broadband video streaming demo (http://communities.intel.com/openport/blogs/server/2007/11/14/). Two things: 1) we're close to launching Intel's SATA based SSD products and 2) we've been engaging you to get more details on your usage models and value propositions. In the last few months, there have been a number of announcements for SSDs in server and enterprise storage applications (e.g. EMC: http://www.emc.com/about/news/press/us/2008/011408-1.htm) including a number of small startups offering solutions targeted for server deployments. Based on my discussions with you and looking at what's going on in the industry, here's my view of the value of SSDs in servers and how that maps to server usage models.

 

As a person who focuses typically on the end-users, SSDs are interesting because they weren't designed to specifically solve an end-user server problem. As I said in my previous blog "because we could", SSD largely exist "because they can". They are what Clayton Christensen would call a disruptive technology. As SSDs are considered for server based applications, I look at how SSDs as a technology can provide greater value when replacing server hard drives (HDDs) or server memory and then build possible usage models from there.

 

When comparing to HDD usage in servers, I start with the following:

 

Performance: SSDs can have much better random access performance as measured by higher IOPS, higher throughput and lower read/write latency. SSDs are typically achieving a least 10 times the number of IOPs as HDDs, at least 2-3 times better random access read rate and on the order of 10 times less read and write latency than HDDs. For random access performance, most SSDs blow the highest performing 15K RPM hard drives away.

 

Power: SSDs use lower power especially when compared to a disk is that is active (i.e. spinning). Given that for most server based applications, the hard disk is always active, this is especially significant. My general observation is that SSDs typically use less than 1/5th of the power of an active HDD. Here they look to be a key technology for making data centers more power efficient.

 

Cost: When comparing cost per Gigabyte, SSDs are higher priced. Given this, SSDs today are largely being considered for applications where storage IO is the bottleneck - where many hard drives can be replaced with just a few SSDs.

 

SSDs can be compared to DDR memory with the same three value vectors:

 

Performance: Unlike the SSD to HDD comparison, memory has higher throughput and lower latency than an SSD. When comparing SSDs to memory for server usages, the primary consideration looks to be latency. SSD reads and writes are on the order of 100s of microseconds. On the other hand, memory based reads and writes are typically less than 100 nanoseconds. Even so, for some applications (e.g. video on demand streaming) 100s of microseconds of latency looks to be acceptable.

 

 

Power: Like HDDs, when comparing active power usage, SSDs draw much less power than DDR memory as measure by watts per gigabyte. How much is dependent on how the application uses memory. But generally, SSDs looked to consume 1/10th of the power.

 

 

Cost: Unlike HDDs, when comparing cost per gigabyte, SSDs are significantly lower priced than DDR memory. Generally, I start with NAND based SSDs as being half the price of DDR based memory. Depending on the size of the SSD and the technology (whether Single Level Cell (SLC) or Multi Level Cell (MLC)) the difference can be much more.

 

 

One final vector to look at is the reliability of SSDs when compared to hard disk drives and memory. Going with just the MTBF numbers being published, SSDs look to be better than HDDs and just as reliable as memory. One area that generates confusion is how the write cycle limitations of NAND technology affect the life-time (as measured by MTBF) of SSDs for server applications. Getting into details on this is a good subject for a future blog. But based on discussions with you, I haven't encountered a server application where the write cycle limitation is the deciding factor in a deployment for SLC SSDs (at least for how we expect Intel's SSDs to perform). For many server applications, it's not the deciding factor for MLC SSDs either.

 

 

Using these value vectors, here are my generalizations for the SSD value for enterprise and portal applications:

 

 

 

 

 

 

 

  • Use SSDs for the server boot device. When compared to HDDs, SSDs enable faster boot (typically 30%), consume lower power, and are more reliable.

  • Use SSDs for high throughput, high IOP, low latency application storage. If storage IO is the application bottleneck, replacing with SSDs shifts the bottleneck back to CPU utilization. Example applications include video streaming, search query, and OLTP.

  • Use SSDs for building a high performance storage tier. Many applications have hot and cold (or long tail) data. By creating a storage tier, the solution cost of a deployment can be reduced significantly. Example applications include using SSDs for improving performance in a NAS or SAN (e.g. what EMC calls Tier 0) or to creating a high performance direct attached storage (DAS) solution (e.g an SSD optimized server).

  • Consider SSDs as a lower cost alternative to placing application data in memory. Many applications create memory based databases to achieve low latency access times. These applications create custom data structures, use RamDisks or rely on caching through the OS (e.g. SWAP). For many IO bound applications, memory is typically being used as a buffer for disk data. The lower latency and higher throughput of SSDs promise to require less memory for buffering while maintaining the quality of service objectives of the application.

 

Bottom line for servers today, SSDs look to be cost effective for applications where storage IO throughput and low latency are key. They move the application bottleneck from IO to back to CPU utilization. Get back to me on whether you agree and what additional usage models you're finding.