Choosing the Right Solid State Drive for Your Storage Network Page 2


Want the latest storage insights?

Download the authoritative guide: Enterprise Data Storage 2018: Optimizing Your Storage Infrastructure

Back to Page 1

Using SSDs in RAID controllers

Even the highest-performance RAID controllers today cannot support the IOPS of just three of the fastest SSDs. I am not talking about a disk tray; I am talking about the whole RAID controller. If you want full performance of expensive SSDs, you need to take your $50,000 or $100,000 RAID controller and not overpopulate it with too many drives. In fact, most vendors today have between 16 and 60 drives in a disk tray and you cannot even populate a whole tray. Add to this that some RAID vendor's disk trays are only designed for the performance of disk drives and you might find that you need a disk tray per SSD drive at a huge cost. You might think this is an open and shut case that says don't use SSDs in RAIDs, but it's not that simple. SSDs in RAIDs have some significant management advantages in the areas of provisioning, RAID levels, sparing and failure management.

Provisioning: Many sites are not going to use a whole SSD for a single file system or application, so you need to be able to divide up the space. RAID controllers excel at this. They support LUN creation, LUN masking and a variety of other provisioning options and features and do this all within a consistent framework that you are used to for all of your other file systems.

RAID Level: Very few of you are going to use RAID-5 or RAID-6 for SSDs, as many RAID controllers cannot sustain the performance of three high-end SSDs, much less in a RAID-5 4+1 or RAID-6 4+2 with five or six drives. Therefore, you are going to use RAID-1 for the most part. Most RAID controllers excel at this, and once again you are working in a framework that is consistent with your other file systems. One important note: If are going to use a RAID level other than RAID-1, the RAID controller must have a high-speed processor, and hardware parity generation and parity check on RAID are also needed to get as much as possible out of SSD resources.

Sparing: If a drive fails in a RAID-1 LUN, the RAID controller is well equipped to address this failure. Hot spares have been a feature of RAID controllers since the beginning. Again, having a consistent way to address the management of spares is a labor-saving advantage of using RAID.

Failure management: This is by far the biggest issue. As I wrote nearly two years ago, SMART statistics for SSDs is a big issue. If an SSD is in a RAID array, you know that the RAID vendor has worked with the SSD vendor to understand the non-standard SMART statistics that the SSD is providing, as there is no standard SMART SSD framework. Knowing that the SSD is being managed for potential failure will give you peace of mind when you consider the critical importance placed on SSDs in the storage hierarchy.

Using SSDs with SAS Controller Cards

Given the pitfalls of putting SSDs in RAID controllers, the other option is to connect SSDs into your system using SAS controller cards hooked into a PCIe slot. The latest crop of SAS controller cards can support around the same number of IOPS as RAID controllers at a much lower cost, but with every good technology comes some bad, as nothing is perfect. These new SAS cards might be able to do the same number of IOPS, but lack most of the features that you get in a RAID high-end controller; from the list above:

  • Provisioning: SAS controller cards can do this, but the software is not as extensive and flexible.
  • RAID Level: SAS cards can do RAID-1. but using RAID-5 or RAID-6 with SSDs likely exceeds the onboard processor's capability of generating parity. I am aware of no SAS controller cards that validate parity on read.
  • Sparing: The SAS card generally can manage this, but again the software is not as robust.
  • Failure management: This is the biggest and most critical issue. RAID vendors spend months validating any drive, SSD or disk, that is sold as part of their system. As part of this validation, the whole issue of SMART data collection, proactive sparing of drives that are expected to fail, and standardized thresholding for returning of failed drives is all taken care of for you.
Many organizations will be using SSDs by the end of this year. The problem is that the storage infrastructure from the file system to the device is not designed for SSDs, which means that you are going to have to make some hard choices about what is important when implementing an SSD strategy. The goal of this three-part series was to provide you an understanding of some of the issues that need to be considered. There are no easy or simple choices; just make the best ones for your environment.

Henry Newman, CTO of Instrumental Inc. and a regular Enterprise Storage Forum contributor, is an industry consultant with 28 years experience in high-performance computing and storage.
See more articles by Henry Newman.

Follow Enterprise Storage Forum on Twitter

Submit a Comment


People are discussing this article with 0 comment(s)