SSDs offer some amazing performance benefits for storage systems, often yielding a 10x read-performance improvement compared with the fastest mechanical drives. SSD's benefit for write operations is hindered by the need for erase-block latency on write, so SSD is usually considered a read device. This is not to say that write performance won't be improved. It will be, but current SSD write performance is about half of its read performance....
In addition to creating a performance issue, writing to an SSD gradually wears it out.
SSD technology is rated for a specific write life (reads have no impact on product life or reliability). SSD chips contain "cells" to record the bits of data. As cells are written, erased and rewritten, these operations gradually degrade individual cells. After enough program/erase cycles, a cell dims to the point where it is no longer usable. The controller maps these bad cells, just as they do with bad hard disk drive (HDD) blocks, to avoid further usage. As the cells fail, the total SSD capacity diminishes until the device must be replaced. Given the high cost of SSDs, IT managers will want to take steps to ensure maximum SSD life. Manufacturers do offer warranties, and some include up to 20% added capacity with their SSD products to mask the effect of bad cells.
There are three predominant SSD fabrication technologies: multi-level cell (MLC), enhanced MLC (eMLC) and single-layer cell (SLC). MLC is regarded as consumer-grade because it is the easiest to manufacture economically and carries the lowest price tag, but it also has the shortest life. MLC chips are rated at for 3,000 to 10,000 write operations. On the other end of the spectrum, enterprise-class SSD uses SLC technology, rated for 100,000 writes. Another option is eMLC, which attempts to deliver the best of both worlds, with approximately 20,000 to 30,000 writes at a lower price than SLC. In any event, you get what you pay for, and it's worth asking about.
Although manufacturers attempt to mitigate the problem through write-caching and sequential writes, smart deployment by IT managers can have the biggest impact on SSD life. Here are the steps to take:
Step 1: Know your application data usage characteristics. Most organizations have no idea what their application data usage characteristics are. The typical workaround is to simply provision the most expensive HDD and overprovision it at that. It's easy and usually works, but results in grossly inefficient capacity management and excessive cost. Most storage vendors offer performance monitoring tools that can determine actual I/O usage. System-level performance characteristics may be enough to provision the correct proportion of SSD storage to meet performance requirements; however, they are not sufficient to contribute to the longevity of the SSD asset itself. Longevity is an important part of SSD total cost of ownership (TCO). Empirically knowing application performance requirements is the only way to get enough performance at the lowest possible TCO.
Step 2: Categorize applications by read I/O intensity. After learning what the I/O characteristics requirements are for specific applications, it makes sense to match read-intensive apps with SSD read-performance capabilities. Although the numbers are black-and-white, there can still be as much art as there is science in making this determination. Few applications are cut-and-dry, read-only applications, although those that are become immediate candidates for SSD provisioning. Most applications are on a continuum of read/write requirements, and this ratio can be used to rank the applications. Those with high read ratios are more likely to benefit from SSD without negative side effects.
Yet, this is where the art comes in. Not all read I/O tasks are equal (actually, there is much more of the "O" than the "I," since we're talking about reads). There is random, sequential and recursive I/O, and performance monitors can't tell the difference. Random I/O is not a problem for SSD if the whole data set can fit into the SSD. Sequential I/O won't benefit from SSD unless this data set can also fit into the SSD. Moreover, sequential I/O apps are often batch-oriented and may only be run occasionally. To provision them on SSDs may not make economic sense unless the app is I/O-bound rather than CPU-bound and is time-critical. Applications with recursive read I/O needs are the "golden profile" for SSD implementations. There's no substitute for savvy human intervention to making this determination.
Step 3: Provision SSD storage appropriately. With the aforementioned data and forethought, storage managers will be able to maximize the usage of an expensive and finite resource. They can provision the SSD precisely where it will do the most good. Critical apps don't necessarily have high performance requirements, so provisioning them on expensive storage just because they're important is a misuse of resources.
Step 4: Don't put cost above business value. Given that IT departments bear the TCO of storage, it's tempting to make deployment decisions purely in terms of cost. However, if an application needs SSD-class performance, that's where it should be deployed, even if the application does not fit the golden profile for the purpose of longevity. Factoring business value into TCO can quickly alter the calculation.
Phil Goodwin is a storage consultant and freelance writer.