By Warren Avery, Storage Switzerland, Analyst

My fellow analyst at Storage Switzerland, George Crump has stated that SSD will become the dominant storage medium for primary storage over the next five to six years.  While I'm not sure about the timeline this makes some sense and six years in IT is a long time.  My question about SSD is not what their role will be in the future but what can you do with them now?

This article will focus on what can we do with SSD right now. Where does it make sense and how can it best be deployed.

SSD’s are not a new technology.  I sold SSDs starting in 1988 with the HDS 7901 (if anyone remembers). What amazes me is the amount of attention SSDs are getting today, the only differences today are capacity (a lot bigger) , price (a lot less) and that nearly every storage vendor either has or has plans to integrate the technology into their current storage solutions.

In the last twenty years as technology has leapt ahead, however, the basic benefit of an SSD is unchanged.  As with any technology the key to a success is to understand your needs.  If you can’t define the problem, finding a solution will be expensive, time consuming and frustrating.

SSDs are amazing performance boosters that quickly and efficiently solve one of two issues: 1) for a given response time the number of transactions processed goes up or 2) for a given number of transactions the response time goes down.

If you can’t put your issue into one of these two categories the benefits of a SSD, at least for today, will be minimal.

That’s it, nothing dramatic and nothing magical; these devices are fast and to the operating system (Windows, Linux, Solaris, HP-UX, AIX, etc.) SSDs are just another disk.  They look like a disk, act like a disk and talk like a disk…they are a disk with no moving parts.  To put SSD into perspective a typical HDD random read/write response time is 3-6ms; SSDs are 0.2ms for Flash drives and .015 for DRAM. Being just another disk any backup software works well. 

A common fear is that using solid state means you lose you data if you lose power; nothing could be farther from the truth.  Every manufacture of DRAM SSD’s includes a battery backup (redundant in some cases) and an onboard disk or uses Flash memory as a backup.  Flash Based SSD’s are already persistent so they have no need for a backup disk or battery.  When power goes away, SSD usually keeps running for some short fixed period in case the outage is temporary.  At the end of this ‘wait’ period the data is written to the onboard storage and shuts down.  When power comes back, the onboard memory reloads the data from the backup disk and in most cases the SSD is ready to go when the servers come online.

So the question becomes where do we use these devices? On a SAN, Direct Attached or NAS? Again the answer is quite simple, wherever you have an I/O bottleneck, often a database like Oracle, Sybase and SQL have high I/O files; these are files like Redo Logs, Roll-back Segments, Transaction logs, syslog, tempbd, high I/O table and indexes.  Each database has tools that identify bottlenecks, Oracle for example provides Statspack.

In addition to tools, DBAs know where to look for performance issues based on experience.  When your car starts to slow down, pull the one way or another and the steering wheel starts vibrating, you have a pretty good idea you have a flat tire…databases are the same.  Given a symptom, the DBA knows where to look and what files could be the culprit.  These performance sensitive files are always being moved by DBAs from one volume to another to reduce contention.  Once a file is identified and moved to an SSD, the moving of files to improve performance is a non issue.

If your company has written in house applications that use any sort of look up table or index and this table is used by a lot of people, this is a very good SSD candidate.  The nice part of these solutions is that these files are usually not very large but account for a huge percentage of I/Os.

Speaking of file sizes, SSDs work best with small blocks (512, 1K, 2K, 4K & maybe 8K) and not with large blocks.  The reasons is that hard drives do a pretty good job of transferring data once the head is over the right sector and large blocks mean the heads don’t have to move.  Once a hard drive has to reposition, then the latency factor becomes huge in comparison to the CPU cycle. An SSD will still outperform a HDD for large blocks, but the benefits are less.

One of the questions that comes up is ‘my disk array has a huge amount of cache, why won’t this compete with the SSD?’  Cached disk arrays are in reality SSD’s sitting in front of the drives with some clever look ahead predictive software, this was true in the late 80s and true today, the only difference today is the huge amount of cache.

The problem with on board cache is read misses.  Slowdowns occur when an application needs a piece of data and the data is not in cache, CPU wait time then go up.  The algorithms currently used do a good job of predicting the next piece of information that a given user may access; the problem is what about a new query or new user.  The access pattern has changed and now the cache has to access the piece of data from a hard drive and the read ahead software preloads what hopefully will be the next piece of data to be requested.  Works pretty well, but not if you have lots of users working on random data…picture an ATM with a long line…the cache doesn’t know who is next in line.  Each new person instigates a new read at disk speeds…typically 3-6 ms.

Some characteristics of applications that can benefit from an SSD are applications with:

High Transaction Rates – implementing an SSD allows more work with fewer staff making the ROI very favorable.  When you see someone taking their hands off the keyboard; waiting for a query or response pay attention as there is probably an I/O bottleneck somewhere.

Database has been tuned – when your DBA indicates that all the tweaking has been done and the next step is a complete rewrite…pay attention.  SSDs do not require a rewrite of any application, this alone can make the ROI extremely attractive given the cost of DBAs and the cost of the current slowdown (lost business, more staff, cost of hardware, new database cost, etc.)

In addition to tuning database performance issues have been addressed buying more powerful servers, adding memory to the servers, adding spindles to reduce contention.  The addition of a SSD sized right with the right files is similar to adding a supercharger to you car.

Peak Times – If your database runs slow at certain times, the cause is usually transaction activity.  An SSD allows more transactions during peak time with no impact on response times.  Usually the only answer to this peak slowdown is more users across more resources.  Again the ROI of flattening a peak load make the ROI favorable.

Conclusion: Do not be afraid of these devices, this is a proven technology over 20 years old that can bring immediate relief to many database performance issues.  The key is to remember what they do…for the same number of transactions the response time goes down or for the same response times the number of transactions increase.  Any other benefits are simply icing on the cake.