All-flash enterprise SAN storage (HPE 3PAR)
Every VPS, private-cloud VM, database host and bare-metal boot volume we sell sits on HPE 3PAR enterprise storage reached over Fibre Channel, not on local disks inside a single server. The storage is a shared, dual-controller, multi-path, all-flash system that survives the loss of a controller, a path, a switch or a drive without the host noticing.
How we build it
We run a fleet of HPE 3PAR StoreServ arrays across our sites. A host never sees an array through one cable: every host has multiple Fibre Channel paths across two independent fabrics, with ALUA multipathing on the host, so a failed port, cable, switch or controller is a path that disappears, not an outage. Production volumes live on SSD RAID 6 provisioning groups: all-flash, with the parity to lose drives and keep serving.
Volumes are thin-provisioned with zero-detect, so a customer gets a full-size disk while only the written blocks consume physical capacity. Arrays at a site are federated, so a volume can be moved live from one array to another without the host knowing, which is how we retire hardware, rebalance load and perform maintenance without maintenance windows.
New hosts are onboarded by a fixed, repeatable recipe: alias and zone on both fabrics, host object on every array in the federation with the correct persona, boot volume created and exported, paths verified from the host, before a single byte of customer data lands. Drives are swept for error counters on a schedule, and any drive carrying even a corrected error is drained live and replaced; we rotate drives out on the first error, not the last. Because the arrays are shared by many customers, every write-side command on them is reviewed before it runs.
What it protects you from
- A single server’s disks dying: the operating system and the data are not on the server.
- A controller, port or path failure: multipath keeps I/O flowing while we replace the part.
- A drive with a rising error count quietly degrading performance before it fails outright.
- Noisy neighbours: we measure I/O per volume and fix the cause at the application instead of letting one workload slow the array for everyone.
In practice
Database tuning removed a flood of needless storage reads. A review of array activity found several customer database servers generating a constant stream of pure reads: database engines with no memory cache configured, so every query went to disk. After the databases were given proper buffer settings, read traffic from that cluster dropped by more than ninety percent, the arrays gained headroom for everyone, and the customers’ queries got faster, because the answer now came from memory.
Every drive with any error history replaced in a day, with no interruption. A fleet-wide sweep checked every physical drive on our production arrays for any error counter at all. The drives with error history were drained live one by one, the data rebuilt onto healthy drives, and the physical swaps completed within the day. The sweep finished with every drive on those arrays reporting zero errors, and no customer saw a change.
Hardware retired without a maintenance window. When an array reaches the end of its service life, its volumes are migrated live onto its sister arrays in the federation while the hosts keep running. The customers on that storage never knew which array they were on, before or after.