It's time I write a long-overdue overview of SolidFire: how it works, how it solves problems, and why service providers love it. So here is Part 1!
First, SolidFire is not the solution to everything. But it is the best in the world at what it does solve, which is why it won Gartner awards for the last two years. Since this is an engineering blog, let's talk about how it works.
SolidFire hardware is regular servers with SSD's and no RAID, so you get commodity hardware prices and a truly software-defined architecture. It protects data by writing it in two places using an algorithm we call Double Helix, and then earns space back with inline compression and global inline dedupe. The global inline dedupe allows for much greater dedupe ratios than anything else on the market, because every block of data written is unique. Other storage solutions have silos of dedupe, pools of blocks that are unique locally but duplicated many times throughout the environment.
Today SF is iSCSI and FCP only. When you create a LUN, SF chooses where in the cluster to place the data, removing the enormous complexity of we call the "placement question." Let's spend some time on that: in most traditional storage environments, you have a couple of storage nodes that form capacity and performance silos. When you scale out to 20 or 1000 nodes, your provisioning encounters a complex question: where do I place this data? That spurs hours of performance and capacity analysis, trending and peaks vs average conversations. On SF, the cluster does it for you.
It also solves the performance question that multi-tenancy brings by allowing you to provision performance. Not just capacity, but performance! SF does this by allowing you to set a minimum, maximum, and burst for each volume, guaranteeing a service level.
I've only scratched the surface on this one: we'll save the scale cluster model and more for the next blog post.
First, SolidFire is not the solution to everything. But it is the best in the world at what it does solve, which is why it won Gartner awards for the last two years. Since this is an engineering blog, let's talk about how it works.
SolidFire hardware is regular servers with SSD's and no RAID, so you get commodity hardware prices and a truly software-defined architecture. It protects data by writing it in two places using an algorithm we call Double Helix, and then earns space back with inline compression and global inline dedupe. The global inline dedupe allows for much greater dedupe ratios than anything else on the market, because every block of data written is unique. Other storage solutions have silos of dedupe, pools of blocks that are unique locally but duplicated many times throughout the environment.
 |
| The SolidFire robot |
Today SF is iSCSI and FCP only. When you create a LUN, SF chooses where in the cluster to place the data, removing the enormous complexity of we call the "placement question." Let's spend some time on that: in most traditional storage environments, you have a couple of storage nodes that form capacity and performance silos. When you scale out to 20 or 1000 nodes, your provisioning encounters a complex question: where do I place this data? That spurs hours of performance and capacity analysis, trending and peaks vs average conversations. On SF, the cluster does it for you.
It also solves the performance question that multi-tenancy brings by allowing you to provision performance. Not just capacity, but performance! SF does this by allowing you to set a minimum, maximum, and burst for each volume, guaranteeing a service level.
I've only scratched the surface on this one: we'll save the scale cluster model and more for the next blog post.
