Why we standardized on all-flash HPE 3PAR

Our block storage runs on HPE 3PAR all-flash arrays, reached over Fibre Channel. That sentence describes a decision more than a product: one array family, chosen deliberately and learned in depth, instead of a menu of storage tiers assembled from whatever the channel offered. This post is the case for that decision, and for asking any host you evaluate whether they ever made one like it.

Five storage tiers on a menu means five platforms run shallowly

Open most providers' order pages and storage is a dropdown: a SATA tier, an SSD tier, an NVMe tier, sometimes a performance tier with no architecture attached to the words. Each row on that menu is a distinct platform someone has to operate, with its own controllers, its own failure modes, its own telemetry, and its own firmware update path. A five-row menu is a purchasing feature. It is also a staffing decision, because engineering attention divides by the number of platforms it has to cover.

Attention divided is depth lost. A team that operates five array families holds five thin slices of experience, and when one of those platforms misbehaves at 3am, the odds that the person on call has worked this exact fault on this exact machine drop with every extra row on the menu. We collapsed the menu instead.

Depth compounds when every incident lands on the same platform

Mastery of a platform is a working inventory as much as a mental one: runbooks written against this platform's real telemetry rather than a generic manual, and engineers on staff who can read the array's internals and diagnose it at firmware depth.

The compounding is the point. Every incident anyone on the team works becomes part of a shared failure library for the same machine, so the tenth encounter with a fault class starts from memory instead of from documentation. Spread the same incidents across a five-platform catalog and the library fragments: most faults get met by someone seeing them for the first time, and a fault met for the first time takes longest at exactly the moment your workload can least afford it.

What the depth buys, day to day

HPE 3PAR Peer Persistence keeps volumes online if an array goes down, and our engineers read service times and path telemetry on the arrays as routine, so a storage question is answered from the array, not from a vendor queue. Telling a sick array from a sick path takes that depth, held by the same people who run the SAN every day.

The machine itself, on the public record

A short tour of what we standardized on, with every claim from the public record. The HPE 3PAR 8450 is the all-flash model of the 8000 family: two to four controller nodes on a passive full-mesh backplane, a design HPE calls Mesh-Active because every volume is live on every controller at once. There is no primary controller to fail over from. The family shipped in late 2015, but the pedigree is older and better: 3PAR was founded in 1999 by Sun Microsystems systems architects, the name literally means 3 Partners, and the company pioneered thin provisioning. In 2010 HP and Dell fought a public bidding war over it, from Dell's opening $18 a share to HP's winning $33, about $2.35 billion. Serious people wanted this machine badly.

The idea that made 3PAR famous is the chunklet, the official term in HPE's architecture paper. The operating system chops every drive into 1 GiB chunklets and builds RAID out of those instead of out of whole disks, so every volume ends up striped across every drive, behind every controller and every port. Two things fall out of that. Performance: there is no hot drive, because no volume lives on any particular disk. And rebuilds: spare capacity is scattered across the whole array instead of parked on an idle spare drive, so a rebuild is many drives helping at once rather than one drive drinking through a straw.

Each controller also carries HPE's Thin Express ASIC, fifth generation in the 8450, sitting beside the CPU and doing in silicon the work software arrays burn cores on: detecting and dropping streams of zeroes inline, hashing blocks for dedupe, computing RAID parity, and stamping end-to-end checksums from host port to drive. That chip is a large part of why the array moves block I/O without drama.

Those are HPE's claims, from the architecture paper, not our lab results. The one worth underlining is the first: HPE's own paper points out that dual-controller arrays drop into cache write-through when a controller dies, which is a polite way of saying they crawl. A four-node 3PAR keeps its write cache mirrored and keeps going. That is the difference between a controller failure that shows up in your latency graph and one that does not.

One honest footnote on that number. HPE's brochures quote the 8000 family scaling past a million IOPS in top configurations, and the larger 3PARs go higher still. The 545 thousand is what an 8450 actually posted under the independent benchmark, with the price sheet attached: 23 cents per SPC-1 IOPS, the cheapest of the ten fastest arrays on the list at the time. Measured beats brochure, so the measured number is the one we quote.

A decade in production means the firmware is settled, the failure modes are documented, the parts are plentiful, and nothing this machine does surprises the engineers who mastered it. That is our doctrine in one sentence, and it has its own post: buy the serious machine.

We deviate only when the job earns it

Standardization without an exit clause is dogma, so here is ours: we deviate only when a job genuinely earns it. The general version of this argument, including why a known baseline is what makes a real exception safe to engineer, covers our network, compute, and fabric decisions alongside storage in we're opinionated about hardware. This is the storage chapter.

If you are evaluating a host, the storage questions worth asking, including the ones most providers cannot answer, are in your host's dirty secret is their storage.