Calculating a Use Case for SSDs

Solid-state disks (SSDs) are an investment that requires serious forethought and a deeper understanding of your storage architecture. How does an IT manager know when to invest in SSDs, and how can he feel confident that the investment is going to pay off? These questions are becoming more relevant as the cost of SSDs has continued to decline over the past few years. This decline has increased the number of application workload scenarios that would be well suited to SSDs.

Investing in SSDs is not the roll of the dice that many believe. There is a process to follow to ensure that you invest in SSDs at the right time to deliver maximum benefit to your organization and know before the product is implemented that it will pay for itself quickly.

The first step is to gather the statistics about your environment. You need information not only on your storage I/O but also on the application servers. For most environments, the tools to perform the analysis are free and readily available. Most UNIX environments can use IOstat and Windows environments can use Perfmon.

A good next step is to look at CPU utilization. As a rule of thumb, if your average CPU utilization is over 33 percent then you more than likely have a bottleneck somewhere else in the application stack. Hitting 33 percent or below indicates that the server CPUs are waiting on something else -- and that something else is very often storage.

To identify if storage I/O performance is truly the issue, the next step is to find a task on the application server that is continuously doing something with the disk. In this task, we want to examine disk queuing or hard-disk queue depth. Queue depth is the number of commands a device is holding in its command queue. When we are discussing if SSD is right for you, the key concern is not filling up the queue and locking up the server. Instead the goal is to ensure that the storage array efficiently handles the queue depth. Perfmon shows the queue depth as a stand-alone statistic; IOstat represents this as percent of utilization, essentially the queue depth x 100 percent.If you always have a queue depth of higher than 1, this means you always have an outstanding command that is waiting on the storage to respond. To improve performance, you must either improve the response time per drive, or, because drives can process commands in parallel, you can also increase the number of drives. The challenge with adding one or more drives is that you get no performance benefit with lower than 1 outstanding disk operation per drive. For example, if you had a 5+1 drive RAID group and you had an outstanding queue depth of 10, then adding more drives to the array should increase performance. However, if in that array group you had an outstanding queue depth of 4, then adding additional drives to the array would provide few, if any, performance dividends.

Two outcomes result from studying queue depth. First, you can see if adding drives is an option to improve performance or if reducing the response time of the drives is the only way to increase performance, once your queue depth is lower than the number of drives in the array. Second, you can determine if the number of drives you need to add to the array group to match the queue depth is going to require an extremely large investment in drives.

In both of these cases the investment in SSDs may be the ideal, and in many cases a less expensive, solution. If you determine that you would require a large number of drives for a smaller dataset to support the application's I/O requirements, solid-state disks can be a much more economical solution. The other option for improving drive performance is to short stroke the drive. Short stroking a drive is the process of only formatting the outer edge of the drive platters, which are also the fastest sections of the drive. Doing so can improve drive response time. The challenge is that this requires additional drives and means having to purchase a very fast, expensive drive -- but only formatting one third of it.

If you cant bleed off the queued commands in parallel, then you can lower response time via SSDs by simply executing more commands because of their raw speed advantage, thus also lowering queue depth. Again, ioStat and PerfMon are valuable tools in revealing the current response time. To improve the response time of mechanical drives, you typically either need to buy faster RPM drives, short stroke those drives, or increase the size of the storage cache. The challenge with response time per drive is that we are stuck with 15,000 RPM drives for the near future. Compared to mechanical drives, where typically 5 to 10 milliseconds is considered a very good response time, solid state disks have dramatically better response time. Flash-based systems today are capable of delivering 0.2 millisecond response times and DRAM-based systems can easily deliver 0.015 millisecond response times.

The final option to improve the response time of mechanical drives is to increase the size of the cache. The problem is that the size of the cache is limited on most systems and the cost of cache memory is often prohibitive. While workloads like sequential logs and most write tasks tend to be cache friendly, the storage system cache still has to deal with the storage software overhead that manages snapshots, replication, and other common storage features and so typically has a response time of 0.5 milliseconds. DRAM-based solid-state disks can offer high memory capacities, utilizing more commodity memory, and are significantly faster for these operations and have less latency.Deciding if you are a candidate for SSDs is a predictable science. The tools needed are standard and are commonly available. Taking a look at CPU utilization, queue depth, and response times should give you the information you need to determine how good of fit a solid-state disk is for you. Even if you think you don't have a performance problem, it is worthwhile to perform this analysis. You may be surprised with the results. SSDs are more attractively priced than ever, which increases the scope of workloads that it may benefit.

— George Crump is founder of Storage Switzerland , which provides strategic consulting and analysis to storage users, suppliers, and integrators. Prior to Storage Switzerland, he was CTO at one of the nation's largest integrators.