Qumulo LogoQumulo Logo

블로그

How Qumulo Transforms Cloud IOPS to Turbocharge Performance and Cut your Cloud Bill

Legacy cloud file storage scales the wrong way.

Nearly every file solution in the cloud is built on managed block disks, and that single choice welds compute and storage together. Need more terabytes? Buy more nodes, even when performance is already fine. You pay for capacity you provisioned rather than capacity you actually use. And every small write hammers those disks with IOPS you're billed for around the clock — all on a storage tier that doesn't even match the eleven-nines durability of the object storage sitting right next to it in the same cloud.

Cloud Native Qumulo (CNQ) is built the other way around: an elastic cluster of compute and cache on top, with cloud object storage — Amazon S3, Azure Blob, Google Cloud Storage, or Oracle Object Storage — as the persistent layer underneath.

We've just published a short animated walkthrough and a companion slide deck, both of which trace client writes and client reads through that architecture. Here's what they show, and why it matters.

The Write Path, in a Sentence

Client write requests land in a mirrored SSD write cache and are acknowledged in sub-milliseconds. Behind that acknowledgment, NeuralCache coalesces, compacts, and compresses thousands of small

writes into a handful of large objects, encrypts everything with AES-256 in Qumulo's protected block format, and commits it to object storage, effectively aggregating hundreds of small write requests into a few efficient PUTs.

The number that matters appears in the corner of the video: 1,000 small writes in, roughly 10 object PUTs out — up to 99% fewer object storage API calls.

Why does that matter so much? Object storage bills per request, and for file workloads those request charges are one of the largest hidden line items in a cloud bill. Managed-disk file systems answer small writes with provisioned IOPS you pay for constantly. CNQ handles those requests at the compute layer so they never trigger an API call.

The Read Path, in a Sentence

When a client sends a read request to CNQ, there’s a greater-than-99% probability that the requested data is already in CNQ’s NVMe cache tier or in system memory: flash-fast, with zero object storage calls. The cache stays ahead of the workload because NeuralCache builds a digital twin of each application's I/O, informed by 14 years of telemetry and more than 250 trillion data points, that predicts future reads before they occur and prefetches them from object storage in advance.

Read requests for cold data warm the cache as they're served. Prediction fills in the rest. And the rare miss becomes one large, efficient GET request from the object storage layer, after which the data is promoted into cache so the next request for the same chunk of data will be served from local cache. Across the global Qumulo install base, cache hit rates run above 99% (which is why the video gives the miss exactly one beat).

miss becomes one large, efficient GET request from the object storage layer, after which the data is promoted into cache so the next request for the same chunk of data will be served from local cache. Across the global Qumulo install base, cache hit rates run above 99% (which is why the video gives the miss exactly one beat).

The net effect: flash-level read and write performance at an object-storage price point.

What Disaggregation Buys You

Because performance and capacity are fully disaggregated, they scale on fully independent axes.

Performance is managed at the compute layer. Start with the minimum of three EC2 instances or VMs, then add or resize nodes in minutes to accommodate workload performance requirements. Scale up during peak load, and then scale back down again when the pressure’s off. Throughput and IOPS follow, while the data never moves or goes offline.

Capacity is served exclusively by the object layer. It grows and shrinks automatically — nearly unlimited, with no capacity planning required, ever, and no forklift expansions.

Run CNQ in a single-AZ for the lowest latency, or deploy it as a true Multi-AZ cluster that can survive a full zone outage with no mirrored replica to buy or fail over. Either way, CNQ deploys from CloudFormation or Terraform in about ten minutes, inside your own account and network. For even more predictable economics, Azure Native Qumulo delivers the same scalability and performance as a fully-managed service for Azure customers.

Why the Economics Win

Every line of the comparison in the deck is structural, not promotional:

●      Capacity at object-storage prices instead of provisioned block disks

●      Performance that scales independently of capacity instead of being locked to it

●      Billing per minute for actual used capacity only, instead of paying for empty or partially-used pre-provisioned disks

●      99% fewer GET and PUT requests, instead of provisioned IOPS, disk sprawl, and uncontrolled API transaction fees

●      Automatic growth, instead of constant re-planning

Object-storage economics plus right-sized compute together add up to a fraction of the TCO of any managed-disk cloud-file solution, baked right into the architecture.

Watch It, Then Run It

The animation covers all of this in about ninety seconds, and the deck gives you the version you can share.

If you'd rather trace some of your own writes through the system, or see how your workloads take to the cloud, Cloud Native Qumulo deploys into your own account in minutes. And if you'd like to talk through how the read and write path maps to your workloads, we'd love to hear from you.

About the Author

Antony Wright is a Senior Systems Engineer at Qumulo based in Sydney, Australia. He looks after Australia and New Zealand, helping customers across the region save time, cost, and risk in their unstructured data workflows from edge to core to cloud.