Solution provider takeaway: Solution providers interested in selling solid-state disk (SSD) should target three key scenarios at customer sites.
On SearchStorageChannel.com, we recently explained the different ways solid-state disk (SSD) technology is being implemented. Now we'll shift attention to identifying customers that can benefit from buying solid-state disk technology.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Within five to 10 years, most active data will be on some form of solid-state disk, but today the reality is that only very specific storage workloads can justify the greater expense of SSD. Almost always, these storage workloads are tied directly to applications that have an impact on the revenue generation capability of an organization. There are three sweet spots to look for among your customers: companies with databases, NAS and environments with a high server count are good candidates to buy solid-state disk.
When evaluating these three areas for SSD suitability, you'll need to understand exactly how the data is being accessed, to make a determination between a DRAM-based SSD and a flash-based SSD. A DRAM-based system has one-tenth the latency of a flash-based system on writes. So in high write I/O situations, DRAM may be the only choice. For DRAM-based SSDs, look to Texas Memory Systems, Solid Data Systems and newcomer Violin Memory. (DRAM-based systems are not available from traditional storage manufacturers right now, and at this point none of those companies have announced plans to support a DRAM-based SSD.) Read-intensive applications are suitable for flash-based SSD from primary storage manufacturers such as EMC, Sun and IBM or from Texas Memory Systems.
Databases are by far the most prevalent applications running on solid-state disk. They most often tie directly to revenue creation, and it's relatively easy to dissect and identify bottlenecks in them, often related to storage I/O performance.
But even if a customer can see the value in buying solid-state disk for a particular database, there's confusion about how big the SSD needs to be. Many companies mistakenly think that they have to buy an SSD big enough to store the entire database. This is impractical for most customers, even taking into account the rapid growth in the size of SSDs. Instead, they only need to buy a solid-state disk drive big enough to store the database's frequently accessed files on one SSD. Identifying those files isn't incredibly difficult; most databases have tools to help. Oracle's Statspack, for example, reports the most frequently accessed files and whether the access is read, write or both. After using such a tool, it becomes a manual process to determine exactly which files belong on the SSD: You should look for undo logs, indices and temporary tables. (Most SSD suppliers, especially those that have been in the SSD market for a while, have customized tools that make the process even easier.)
Surprisingly, the second most common area for buying and deploying solid-state disk is on NAS systems. Using SSD on NAS makes sense when there's a small amount of frequently updated data. A good example of this is in a Web environment with a large farm of servers that need to access similar data on the same file system at nearly the same time -- say, a comparison shopping website on which people are searching for iPods. Loading this subset of data onto SSD is ideal, because even though the data is being accessed through the latency-heavy Internet, there could be a thousand servers making the exact same request at almost the exact same time, and those requests are being processed locally at the website's data center. A delay here, and customers will go to another site.
Such a scenario is a perfect example of a read-intensive use of SSD on NAS. There are also write-intensive use cases for SSD on NAS; a photo sharing site, for example, will get hammered with uploads of files the day after Halloween. Obviously, these are all writes; storing those files to an SSD first and then moving them to hard disk soon after is a good use of SSD in a write-intensive environment.
Web services isn't the only area where buying solid-state disk makes sense for file-based reads and writes. Most grid-based compute clusters that have hundreds of servers accessing the same data or data areas require fast access to data, and the mechanical nature of hard disk can become a bottleneck. And biometrics is another area where NAS-based SSDs are used. Although a biometrics scan is typically a single operation, speed is critical because an image (thumbprint) needs to be found, read and compared quickly. A delay here, and the person walks into the door rather than having it open for them.
High spindle counts
This sweet spot actually ties back to the first two; in some cases, this one may be the easiest to identify. If a customer is constantly increasing server count on a particular application for better performance, they are quite possibly a candidate for buying solid-state disk. But, before steering them in that direction, it's important to make sure that they do indeed have a storage I/O problem rather than a compute resource problem.
High spindle counts, especially if your customer is short stroking drives, are ideal candidates for SSD. Short stroking a drive means formatting it so that only the outer sectors of the disk platter are used to store data. Short stroking delivers excellent performance but is a costly way to get there because high-speed (15,000 rpm) and low-capacity drives are typically used, and the low capacity is further reduced by short stroking. In almost every situation, these applications are deployed across a very large number of drives that have been short stroked.
If you identify one of these situations, get ready to be a hero. With today's memory prices, it is highly likely that you can deliver a solid-state disk solution for less than what they've invested in their compute grid or short-stroked disk infrastructure. SSD can deliver more IOPS per GB than hard drives can; as a result, you can offer better performance, at a lower cost, while being more power- and space-efficient.
While the most obvious uses of SSD (and the ones that will be easiest for you to identify and tackle) are the three we talked about above, applications like data warehousing, file system metadata acceleration, nonlinear video editing and software versioning applications can also be good reasons to buy solid-state disk. In determining where customers can make use of SSD, you should look for a productivity-limiting storage I/O bottleneck that's directly tied directly to restriction of profits.
In today's environment, you shouldn't look to move the entire data set to SSD, nor should you try to move the entire Tier 1 data set to SSD. You should instead look for specific files (or subsets of files, in the case of databases) that are storage I/O-constrained and which could improve the performance of critical applications by being placed on SSD.
About the author
George Crump is president and founder of Storage Switzerland, an IT analyst firm focused on the storage and virtualization segments. With 25 years of experience designing storage solutions for data centers across the United States, he has seen the birth of such technologies as RAID, NAS and SAN. Prior to founding Storage Switzerland, George was chief technology officer at one of the nation's largest storage integrators, where he was in charge of technology testing, integration and product selection. Find Storage Switzerland's disclosure policy here.