Using solid state for primary storage
For vendors that implement solid-state storage directly as a primary data store, many use the standard disk-drive form factor. This implementation method is simple to understand and is compatible with current subsystem designs and configuration processes. The one downside to this approach is that many of today's controllers and subsystems weren't designed for disk drives with an order of magnitude of faster performance at the drive level, so vendors typically don't support a large system completely full of solid-state disk drives. But this is changing as vendors design and build improved controllers that can handle many more solid-state drives. The good news is that significant performance gains can be achieved with a relatively small number of SSDs, often only one full or partial drive shelf. Some users are reporting five to eight times performance gains for some workloads with a relatively small amount of solid-state storage.
We're also seeing an increasing number of solid-state-only storage products available today and planned for release over the next several months. These systems are designed to use solid-state storage as the primary store, with capacities in the single- or double-digit terabytes today and larger capacities coming soon.
For users who have implemented solid-state storage as a primary store, the big question focuses on what data to put on the solid-state storage. There are some obvious candidates, such as database indexes, heavily accessed database tables or temporary scratch areas, log files or any other hot spot. However, this is often not a static solution. Some data that's hot today may not be hot tomorrow. So storage administrators, database administrators or other IT technicians may have to continually monitor data usage patterns and be prepared to make adjustments on a fairly regular basis. In some cases, this increased management burden may be too much work and operational expense to be worth the tradeoff for increased I/O performance.
The answer is to provide an automated way for the storage system to identify the hot data and move it onto the solid-state storage automatically, then move it to slower storage when it no longer requires solid-state performance. Many vendors provide forms of tiering software that does exactly that. This software observes the I/O patterns for a time and then moves the data in a way that's transparent to the host applications. Many of these automated solutions allow the administrator to determine what activity level defines "hot" data, set the time period over which the observations are made, and then set a separate parameter that controls the frequency of data movement (anywhere from hourly to weekly). Some of this software has the ability to make recommendations about the data tiering based on the observations it has made, such as recommending a 10%/90% mix of solid state vs. spinning disk. Today, many of these automated data movers perform the data movement at the LUN level; sub-LUN-level data movement is expected from several vendors within the next six to 12 months.
The solid-state-only storage products eliminate the need to move data from faster to slower storage because all of the data is on fast storage. These systems appeal to customers who want to put an entire application and its data on solid-state storage. At today's price points, these solutions tend to be deployed for critical applications only. The decision (and budget) to acquire them tends to come from line-of-business owners or architects rather than from the IT department.
This was first published in June 2010