My first exposure to Pure Storage was at Tech Field Day in their offices in Mountain View. A central part of the message was that the objective was to produce all-flash enterprise storage for the cost of hard drive-based storage. In the intervening years, Pure Storage has focused more on performance with the FlashArray//X series delivering sub-millisecond response time for high-performance workloads. This year at Pure Accelerate, I saw a return to those older values; the value proposition for FlashArray//C is all-flash at the price of hard disk or hybrid arrays. This new array series is more about cost-effective capacity than all-out speed.
Architecture
First off, this is a FlashArray, and it runs the Purity OS that is on the FlashArray//X series. It uses deduplication and compression to increase the effective capacity of the array. All of the data services like cloning, snapshots, and replication all work the same as on //X and replication between //C and //X is a prime use case. I was surprised that the FlashArray//C is end-to-end NVMe, including NVMe over Fabric (NVMe-oF) despite being a capacity rather than a performance product. Because FlashArray//C uses the same Purity OS as FlashArray//X, the management is shared too. The same user interface on the arrays, the same APIs, and the same connectivity to Pure1 for fleet-wide visibility.
The big difference is that FlashArray //C is designed to accommodate higher overall capacity, along with high-density NAND, such asQLC. QLC is dense but challenging to work with. There are not a lot of electrons per level in the flash, so the cells need to be written, read, and maintained carefully. QLC cells don’t have much endurance; you want to avoid regularly erasing and overwriting cells so that they don’t wear out. The net result is that QLC is about high capacity systems that seldom overwrite data, rather than high performance. In an SSD based array, there is separate garbage collection in each SSD, and again by the array controllers. Pure uses Direct Flash Modules (DFMs) where the array controller has more visibility to the flash compared to conventional SSD controllers which obscure the flash characteristic. The DFM and some NVRAM-based cache are central to Pure’s ability to minimize erases of the QLC, removing the need to massively over-allocate QLC capacity to get excellent operating life.
All-Flash Capacity and Consistent Performance
FlashArray//C is a capacity-optimized product, so it will be most valuable where the cost-per-gigabyte is a significant factor. It is still an all-flash array so performance will be better than hard disk-based arrays. The listed latency for FlashArray //C is 2-4ms, while a typical hard drive is 9-15ms. A significant challenge with hard disk and hybrid (flash plus hard disk) arrays is that the difference between the best and worst latency is vast. A hybrid array might deliver 1-2ms latency for 80% of I/O but might take 10ms to respond to 5% of I/O, the result is that many applications see performance limited by that 5% rather than the 80%. FlashArray//C has only one tier of storage, so the 2-4ms response time is for almost 100% of I/O and applications see consistent good performance. For applications that need sub 1ms latency, FlashArray//X is latency-optimized, providing consistent high performance and low latency for more performance-sensitive applications.
Uses
I expect a lot of cost-conscious and general-purpose workloads being deployed on FlashArray//C. The performance is excellent for lower criticality workloads, including large populations of virtual machines. There are a lot of cost-conscious deployment scenarios, such as branch offices, that will be good candidates for FlashArray//C. Pure is also expecting that customers will replicate their FlashArray//X systems to FlashArray //C for disaster recovery. Using FlashArray //C as the destination will help control the cost of DR, particularly since you can replicate multiple FlashArray //X to a single FlashArray //C. Replicating all of your VMs to your DR location, even if you don’t plan to recover all of them, protects you from unexpected dependencies where a non-replicated VM might block the recovery of an application. FlashArray//C is not a high-performance play; it doesn’t deliver the low-latency response of a FlashArray//X. The difference in performance will mean many customers with both FlashArray//C and FlashArray//X for different workloads, even in the same datacentre.
