What to consider before investing in an all-flash array
No application needs flash storage, per se. However, I would be wrong to posit that most apps' performance wouldn't benefit from it greatly. We find ourselves at a debatable inflection point today, one where the effective cost per GB of enterprise flash rivals that of high-performance SATA drives, depending on who you ask (effective cost per GB calculates cost per GB after data reduction services are factored-in). Until the price of flash dips definitively below that of disk, however, some important considerations are in order as you evaluate, select and implement an all-flash array (AFA) investment.
Flash storage doesn't fix everything.
Flash storage solves two problems: storage performance and data services. SATA array controllers are inherently limited by the performance of the mechanical drives that sit beneath them. Drive speed, seek time and rotational latency introduce a mechanical speed limit to a SATA array. Data services such as compression and deduplication, high availability, tiering and replication all add overhead that detracts from the core performance of the read and write operations of the applications residing on the array.
Flash, on the other hand, bears no such barrier. As such, manufacturers can leverage more and more powerful CPU, RAM and caching technologies to appreciably enhance both the performance and data service capabilities of the array. As these enhancements are made, commensurate upgrades are necessary upstream of the controller to reap the full benefit of flash storage performance: fibre channel, HBA, NIC and switching upgrades all add unavoidable cost to an AFA investment.
Strategy #1: All Tier 1's
Customers practicing this approach place all Tier 1 workloads, however they define these, on flash storage. This strategy works, but is potentially wasteful. Assuming the environment consists of both flash and disk-based storage, and that all workloads are appropriately sized and placed at compute, then there is a good chance these customers have prematurely and wastefully evacuated their SATA arrays.
Flash storage all but eliminates the latency attributable to random or non-sequential IOPS. Random IOPS are the operations driven by the so-called "IO-intensive" workloads like databases, VDI and some virtualization. What makes these workloads IO-intensive is not only the volume of IO they generate, but also the randomness of the read requests to the drive. On disk-based systems, random IOPS induce latency to the application as they contend with the seek time and rotational latency of each drive. On flash systems, two blocks of data might have completely random block addresses, but this information has no bearing on neither where that data is physically stored nor how quickly it is retrieved.
Sequential IOPS, in SATA parlance are blocks of data that may be written or read sequentially on the exact same sector of the disk drive. Seek time is effectively zero and rotational latency is negligible. Applications exhibiting these IO characteristics - even Tier-1 applications - will likely fare perfectly well on a SATA array; again assuming they are properly sized and placed at the compute layer.
The drawback of placing only Tier-1 workloads on flash storage is one of both performance and efficiency. There are very likely Tier-2 (or lower) applications whose IO characteristics would benefit greatly from flash; at the same time, a stringent Tier-1 policy places workloads on flash that don't necessarily need it. The reason why organizations take this hard-and-fast position is the challenge they face identifying the IO behavior of their workloads; they don't know which workloads are generating the greatest IO, the magnitude of that IO or its sequencing.
Strategy #2: Cluster-Specific Flash Storage
The second and likely most common flash storage strategy is attaching dedicated clusters to the flash SAN: virtual apps, virtual desktops and databases. The reasoning behind this approach is obvious: these are the notorious non-sequential, IO-intensive applications that support heavy and unpredictable client load. Confining these workloads to an AFA backend is clean and easily managed.
The issue I see with this approach is it indicates a short-sighted flash strategy. It likely means the organization has committed to a flash architecture (scale-out or scale-up) specific to that cluster - whatever it may be - without forethought of how that architecture will suit future workloads or how that cluster boundary impedes overall efficiency.
This strategy presents an opportunity to quickly discuss an oft overlooked topic: block size. The term "IOPS" actually means very little unto itself without the qualifying block size. Many storage vendors market their products as "X-hundred thousand IOPS", however, these statistics are benchmarked at a block size of 4KB. While some applications read and write in 4KB blocks, many do not, and for these applications you can expect hampered performance on AFAs not normalized for larger block sizes. The takeaway here is that not all AFAs are created equally, and you should vet these specs carefully against the requirements of the application sets you need to support.
Strategy #3: VMTurbo Decides
I will keep this section short. Some customers know they will eventually adopt flash across the board, as projects and budgets allow. A subset of these have established enough trust with VMTurbo to allow it to identify and automate the auto-tiering of workloads onto the arrays they own. This tiering matches workload IOPS requirements to the underlying IOPS and storage capacity of available datastores, while also matching the resource requirements at the compute and network layers. The net result is that workloads needing flash reside on flash and workloads that don't, don't.
Your checklist for a long-term flash storage strategy
Until flash and disk are inarguably fungible, organizations should proceed with prudence and think long-term about their flash storage strategy. If the ultimate destination is an all-flash data center, then these are the things to consider:
- Choose the architecture that most appropriately meets your provisioning and application lifecycle management processes
- Understand the peripheral upgrades you will need in order to fully maximize flash storage performance
- Select a vendor whose performance and data services are tested against the actualworkloads they will support in production (sorry, IOmeter)
- Have a migration strategy based on resource consumption, and a roadmap to get you there
- And lastly, when you rent a cloud server, do you actually trust you're getting a real SSD on the backend? I sure don't.