Deploying Enterprise Apps on Solid State Drives

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Flashed-based solid-state drives (SSDs) are becoming a big issue for enterprise storage users; a number of customers I work with are planning for this new “tier 0” data storage for a number of reasons. It could be as simple as IOPS per watt, IOPS per dollar, or for some applications, bandwidth per GB/sec of storage.

SSDs have a number of disadvantages compared to traditional disk storage, the biggest by far being cost. There are those who claim that spinning hard drives will soon be a thing of the past because of flash SSDs, but I can’t see that happening anytime soon, and if it does, the devices that replace spinning hard drives will not be based on flash and won’t appear much before the end of this decade (see I/O Bottlenecks: Biggest Threat to Data Storage). Vendors have been claiming tape is dead for the last 20 years, but it continues to play a big role in data protection schemes. There will always be tiers of storage, it seems.

This is the first in a three-part series on planning for flash SSD deployment. The first article will cover applications that will benefit from flash, along with some of file system and other issues for deployment. The second article will cover hardware issues, and the third will cover SSD design issues and their use with SAS and RAID controllers.

Applications that Benefit from SSDs

We all know that parts of some applications, such as databases, benefit from high IOPS architectures, but what should you be considering when trying to bring flash SSDs into your architecture?

The real benefit of SSDs for applications involves latency for small block I/O requests. While the fastest 2.5-inch 15K RPM drive might be able to do 250 random IOPS, most enterprise SSDs should be able to easily sustain 40,000 IOPS for read and 30,000 IOPS for write in today’s world. Of course, you need to have the hardware to achieve this performance, and that will be discussed in part 2 of this series.

There are obvious parts of heavily used databases that can benefit from SSD technology, and the most obvious are database indexes. The second most obvious part of databases that can benefit from SSDs are database logs files. Both of these are generally smaller than the table space and are often placed on 15K RPM disk drives today, and even then are still frequently limited in performance. Performance tools such as iostat, sar and other performance monitoring tools are often used to evaluate the high latency found on storage attached to the LUNs associated with these devices.

Read the rest at Enterprise Storage Forum.