This content is part of the Essential Guide: Essential guide to the all-flash array market

How to buy an all-flash storage array

A solid request for purchase is key for any storage purchase. But, an all-flash array RFP requires additional info you may not have included previously.

All-flash storage arrays are in demand and the adoption rates are increasing. In some shops, the all-flash storage array is becoming the standard tier-one storage platform for mission-critical active data, and we are hearing that many other organizations are including all-flash in their future plans.

When you have made the decision to acquire a solid-state storage system, preparing the vendor request for proposal (RFP) is critical. Your RFP must not only require typical storage RFP information, such as raw and usable capacity and data protection features, but it must also take into account solid-state storage's unique performance characteristics to ensure you are evaluating systems that best match your technical and business needs.

This article is the second in a series that walks you through the buying process for an all-flash storage array. The first article described why IT shops are now considering all-flash arrays for tier-one storage and which applications derive the most benefits from flash's high-octane performance improvements.

In this article, you will learn the features, performance metrics, and purchasing criteria you need to include in the vendor RFPs to ensure that your all-flash storage array purchase will result in the right device for your environment.

RFP basics

There are a number of administrative items your RFP should contain, in addition to the technical requirements.

The RFP should include some background information about your organization and your current data center environment, including general areas of expertise of your IT staff along with the hardware and software currently in use or planned for the future. Diagrams can be helpful here. Also, you should state your general goals to be accomplished with the RFP. For example, is the goal to replace existing storage or add to existing storage? Also, which business applications will run on the new storage?

Typically, RFPs also include a timeline of the selection process, including the date the RFP is published, the deadline for questions to be submitted regarding the RFP, the deadline for proposal submissions and the date of the final selection. Many RFPs include a description of the criteria by which vendor submissions will be evaluated, such as a point system, or weighting of certain items. Other administrative items that should be included in the RFP are requirements for insurance, security, compliance with various regulations, and a statement that indicates that you are not paying for the work required to respond to the RFP.

Once your RFP is set up to gather all the vendor and product information you will need to make the best decision, you can move on to technical criteria.

Storage capacity and performance

Specify your desired storage capacity and performance needs, not only for use during the first year, but for each of the following three to five years. You should have a good understanding of your storage capacity growth trends over the last two or three years, and your expected growth.

Prices for flash storage are expected to drop each year, so it can be to your advantage to structure the RFP so that you obtain a certain amount of capacity now and add additional capacity at lower cost in future years, aligned with your capacity growth projections.

When it comes to all-flash storage arrays, knowing your current application storage performance metrics and trends are even more important than the capacity. There are three basic storage performance metrics: IOPS, throughput (measured in megabytes per second) and latency. You need to know these metrics for all the applications that you intend to put on the all-flash storage array, and how these have changed over the last year or two.

Different workloads have different performance characteristics, and you need to profile your workloads. For example, online transaction processing workloads tend to push IOPS more than throughput, and require lower latency. On the other hand, data warehousing workloads tend to push throughput more than IOPS and can tolerate higher latencies. Virtual server and desktop environment workloads can be latency-sensitive. You will need to specify the minimum or expected performance metrics in terms of latency and IOPS or throughput for each of your applications in the RFP.

In addition to knowing your application performance metrics, you need to understand the read/write mix of your workloads. This is because solid-state storage is available in multiple types: read-intensive, read-write mix and write-intensive. You need to specify the read-write mix of your applications in the RFP so that the product vendor can supply the correct mix of flash in the system.

You may have noticed an assumption of block storage in the previous paragraphs, but, of course, file storage must be considered as well. Key metrics for file storage include the number of files (and file systems), growth trends over the last year or two, and projections for the next three to five years. For certain critical systems, it is also important to track how frequently new files are added and how many files are typically open at any given moment. File system metadata operations are different than regular reads and writes, so these metrics are important. Similar information is needed regarding object storage, if you intend to use the all-flash storage array for that purpose (assuming the array supports it).

Power supply is another item that will need to be included in the RFP. Most modern storage systems sold in the U.S. can run on 110/115/120 volts or 220/230/240 volts. We have found that the power supplies used in storage systems run more efficiently at 220/230/240 volts than at the lower voltages.

Data reduction

As we discussed in the first article in this series, many of today's all-flash storage systems incorporate capacity optimization, or data reduction technologies, such as compression and data deduplication. By including these technologies, all-flash storage array vendors can drive down the price per gigabyte by charging for usable or effective capacity (after dedupe).

In order to help level the playing field -- and make for a more neutral RFP -- your capacity, performance, read-write mix, block sizes, numbers of files and objects all play a role in determining the usable capacity. Different data compresses at different rates, and some data that doesn't compress well deduplicates well and vice-versa. If you are evaluating all-flash storage arrays that have compression and data deduplication enabled by default, then you need to provide enough data about your workloads and data types to get a reasonable estimate of the expected compression ratio and data deduplication ratio.

Operating environment support

The RFP should also include statements about your use of server virtualization hypervisors, such as VMware and Microsoft Hyper-V. Some all-flash arrays offer integration with these technologies.

Operating systems (OSes) and applications running inside of virtual machines (VMs) have different mechanisms for handling multi-pathing I/O, caching, and visibility to the actual storage, so those issues need to be identified as well.

If you have a virtual desktop environment, for example, how does the new all-flash array handle boot and login storms? How many virtual desktops might be expected to boot and log in at the same time in your environment now and in the future?

Data protection

All-flash storage arrays offer various data protection methods, including snapshots, clone copies, remote replication and others. You need to include which of these you require, how many copies of your data you wish to keep. For remote replication, you need to specify whether you plan to use synchronous or asynchronous replication.

Data also needs to be protected where it is stored. You should understand any RAID, erasure coding or equivalent mechanisms that are used to protect against drive or module failures, and how many drives or modules can fail before a rebuild is required. The rebuild times needed to reconstruct data from a failure can be significant if you have petabytes of data to protect.

The RFP should also mention any existing data migration, backup and restore processes and applications you use.


The RFP should require warranty information for the entire system and for replacement parts, if those are different. These days, good enterprise solid-state technology often comes with a five-year warranty. Some product vendors are attempting to include a "bytes written" or "mileage" type of warranty on solid-state storage. This is because NAND flash has a limited number of writes per cell that can be performed. Enterprise-class NAND flash modules or drives usually can write multiple times their capacity per day, especially the "write-intensive" type of flash.


Finally, the RFP should include a line item listing prices for all hardware and software components, including the list price, discount applied and final price. Don't forget to include maintenance, support, implementation services, training and any other services you may need. Most vendors will also be happy to discuss financing options such as leasing or deferred payments, and if you are interested in these, be sure to list them in your RFP.


In many ways, preparing an RFP for a solid-state storage system is the same as a traditional hard disk drive system. Raw and usable capacity, data reduction, and data protection data are important. However, in many ways it is different. The cost of solid-state storage and its unique performance characteristics mean you must include more application and workload information to ensure that you get the best system for your technical and business needs.

Next Steps

All-flash array purchase considerations

Say goodbye to boot storms with all-flash arrays

Hybrid vs. all-flash: When some flash isn't enough

All-flash array in-depth: The role of big storage

All-flash arrays: Will time run out for mainstream acceptance?

Dig Deeper on All-flash arrays