CNQ Google Cloud Instance Explorer

Interactive companion

Which ceiling is lowest?

A Cloud Native Qumulo node on Google Cloud inherits its performance ceilings from the Compute Engine machine type underneath it. Pick a size and a workload shape, and this page ranks the two published Google Cloud ceilings that actually apply.

Read this first

These are Google Cloud's published limits for the three machine families Qumulo supports on Google Cloud — Z3, N2 and N2D — plus Google's own Compute Engine list pricing. They are not Qumulo guidance and not a benchmark.

Google ships new machine generations regularly and Qumulo's supported list moves with them. For the most recently supported machine types and configurations, refer to Qumulo's guide to deploying Cloud Native Qumulo on Google Cloud with Terraform and the provider's supported machine types reference before you size anything.

Pick a size and a workload shape

The 17 machine types shown here are exactly the sizes Qumulo's provider supports — nine Z3 sizes (16/22/32/44/88-vCPU highlssd, 14/22/44/88-vCPU standardlssd — note the asymmetry: highlssd has no 14, standardlssd has no 16 or 32) plus all four N2 and all four N2D sizes. Larger Z3 sizes and the Z3 bare-metal type exist on Google Cloud but aren't in the supported list, so they aren't on this page either.

Machine family
Size
Workload shape
 

    Network egress against the write cache, across the family

    Both ceilings in megabytes per second, so they can be compared at all: published network gigabits per second, converted, against what Qumulo's provider actually provisions for the write cache on this machine type — not Google's platform maximum for Hyperdisk or Persistent Disk Balanced. Network figures are Google's default network tier throughout. The last column answers for the workload shape selected above, so it changes when that does.

    Scroll the table sideways to see every column.

    Size vCPU Network MB/s (per node) Write cache MB/s (provisioned, per node) Write cache as % of network Lowest published ceiling
    Mandatory caveat. This ratio is our arithmetic on Google's and Qumulo's own figures, not a benchmark. The write-cache column is what Qumulo's Google Cloud provider actually provisions, aggregated across every attached write-cache disk — not Google's platform maximum, and not a single disk's figure either. Z3 uses Hyperdisk Balanced (half-duplex for both IOPS and throughput). N2 and N2D use Persistent Disk Balanced (half-duplex for IOPS only; read and write throughput are independent) — but Persistent Disk Balanced performance isn't provisioned independently (only Hyperdisk accepts provisioned IOPS and throughput), so N2/N2D's write-cache ceiling isn't ranked on this page at all; see the limits below. Google's own network-bandwidth documentation states that published egress bandwidth includes data transferred to all Hyperdisk and Persistent Disk volumes, so network and write-cache traffic share one physical NIC on Google Cloud and these two ceilings contend with each other, not just individually cap out. Treat this as a planning heuristic for sizing, never as a performance model.

    The network curve across sizes

    Maximum published network egress bandwidth (default network tier), per family. The horizontal axis is vCPU count on a logarithmic scale, so equal steps are equal doublings.

    Scroll the chart sideways to see the full range, or read the figures in the table below it.

      N2 and N2D publish identical default-tier egress at every shared vCPU count, so those two runs sit on top of each other.

      Show the plotted figures as a table

      Scroll the table sideways to see every family.

      What this page cannot tell you

      • The write-cache disk type on Google Cloud isn't uniform across families. Z3 uses Hyperdisk Balanced, but N2 and N2D default to Persistent Disk Balanced instead — a different Google product with different half-duplex behavior (see below), whose performance isn't provisioned independently (only Hyperdisk accepts provisioned IOPS and throughput), so N2/N2D's write-cache ceiling is not ranked on this page. Google's own network-bandwidth documentation states that published egress bandwidth includes data transferred to all Hyperdisk and Persistent Disk volumes: network and write-cache traffic do share one NIC on Google Cloud. Three further points apply everywhere CNQ runs, Google Cloud included: mirroring writes to other nodes rides this same shared NIC, concurrently with client and GCS traffic; client protocol write operations don't map one-to-one with the transactions that reach Qumulo's write cache (the filesystem scheduler can combine multiple queued writes into a single internal transaction, improving efficiency under sustained write load); and write-cache mirroring is not a fixed pairing between two nodes — Qumulo mirrors write-cache data across the cluster so majority quorum holds and the data survives, a durability/quorum mechanism rather than a data-placement one, which means a write can generate backend network traffic to more than one node, beyond what a single node's published ceilings describe.
      • These are published Google Cloud ceilings, not measured Cloud Native Qumulo results. Nothing on this page was benchmarked, by Google, by Qumulo, or by us. A ceiling tells you what you cannot exceed. It does not tell you what you will get.
      • Every figure on this page — every card, chart and table — is per node, not cluster-aggregate. A Cloud Native Qumulo cluster is always more than one node, so cluster capacity is not simply this page's per-node ceiling multiplied by node count. Network is the candidate least like a clean multiplication here: Google counts a write against the egress budget twice — once landing in the write cache, again on the eventual flush to Cloud Storage — and cluster-mirroring traffic rides that same NIC on top of it, both already covered above. Size a node with this page; size a cluster with Qumulo.
      • A single-threaded or single-connection client will not see cluster-aggregate throughput. Cloud Native Qumulo is a distributed file system: reaching the aggregate performance a multi-node cluster is capable of requires concurrent operations — multiple threads, multiple connections, or multiple clients — spread across the cluster. A single client issuing serial, single-threaded I/O is bound by what one node (and one connection) can do, not by the cluster's combined ceilings. Size for the concurrency your workload actually generates, not just its total bytes or operations.
      • No public source maps Cloud Native Qumulo operations per second to core count. Cores do protocol handling, metadata work and data-protection math. How far that dial turns for your workload is something you have to measure, not read off a page.
      • Z3's built-in Titanium SSD and N2/N2D's Local SSD play opposite roles, not the same one. Z3's local Titanium SSD is reference-only — its write cache is Hyperdisk Balanced. On N2 and N2D, Qumulo's provider attaches Local SSD as read cache, which those machine types don't carry by default. Z3, despite having up to 36,000 GiB of built-in Titanium SSD sitting on the box, attaches zero read-cache disks — none of that capacity is used as cache on Z3. The Local SSD card below reflects each family's actual role and is never ranked against the network or write-cache ceilings.
      • Google's published bandwidth figure is an egress ceiling, accounted per instance. For traffic on routes within a VPC, there's no purposeful ingress restriction. For traffic entering from outside the VPC (internet-sourced), Google does publish a ceiling — actual inbound throughput may be under ~30 Gbps or 1.8M pps, best-effort and explicitly outside any SLA. On machine types with multiple physical NICs, this limit applies per-NIC, not per-instance. Google's own docs state maximum egress is "generally 2 Gbps per vCPU" up to the machine type's cap. This page assumes traffic from a node to Google Cloud Storage — reached through Private Google Access, off the public internet — still counts as egress against that same ceiling, the conservative reading since it still leaves the VM's NIC, but no official Google or Qumulo source confirms this for CNQ by name.
      • On Google Cloud, published network egress figures also account for traffic to attached Persistent Disk and Hyperdisk volumes. The large-file-write and cache-miss-read shapes above account for this directly, rather than ranking network egress and write-cache throughput as two independent ceilings: both draw on this one shared budget, so treating them as independent would understate the real constraint. For those two shapes, a sustained write (or a cache-filling read) draws on that one budget twice — once landing in cache, once moving to or from GCS — so this page reduces the raw published egress figure rather than ranking it in full. How much depends on which write-cache type the size actually uses, not a single fixed factor: where the write cache genuinely is Persistent Disk (N2 and N2D's pd-balanced), the page applies Google's own documented figure directly — 60% of egress allocated to writes, divided by the 1.16× zonal replication multiplier, ≈ 51.7% of raw egress, Google's formula rather than this page's approximation. Z3's Hyperdisk Balanced keeps this page's own cruder 2× floor instead: Hyperdisk's own performance documentation describes a fully separate, self-contained ceiling model with no mention of network contention at all, so Google's Persistent-Disk-specific formula isn't borrowed for a product it doesn't apply to. Either way, the reduced figure shown is a single confirmed point, not a range with an unresolved floor beneath it. Cluster-mirroring traffic, which does ride this same NIC (see below), remains unquantified in bandwidth terms and is a separate, still-open gap.
      • Hyperdisk Balanced and Persistent Disk Balanced are half-duplex differently. Google's own Hyperdisk documentation states plainly: "the IOPS and throughput limits are shared between read and write operations" — half-duplex, for both IOPS and throughput, and safe to attribute directly to Google. Persistent Disk Balanced (pd-balanced, used by Qumulo's provider on N2 and N2D) publishes separate read and write throughput columns with separate caps, which we read as read/write throughput being independent of each other — an inference from that published structure, not a position Google states in so many words the way it does for Hyperdisk. Either way, per the bullet above, disk traffic on both types still draws down the same published network egress ceiling, so "independent of each other" describes reads versus writes on the disk, not independence from the network figure.
      • How many write-cache disks Z3 and N2/N2D attach, and what that means for the provisioned figure. Z3 and N2/N2D attach different numbers of write-cache disks at different vCPU tiers; the aggregate figure this page ranks reflects what Qumulo's provider actually attaches and provisions at each size, not a single per-disk number multiplied out. N2 and N2D's disks have no provisioned IOPS/throughput setting (only Hyperdisk-type disks accept one), so there is no flat figure to rank there at all; the real ceiling depends on Persistent Disk's own size/vCPU scaling formula and disk-size inputs this page doesn't have, so N2/N2D's write-cache candidate is shown for context only and never ranked.
      • Units: this page uses megabytes per second (MB/s, decimal) throughout. Gigabits per second are converted to MB/s as Gbps × 125, and Google's published MiB/s figures for Hyperdisk and Local SSD are converted at 1 MiB = 1.048576 MB, rounded down. The write-cache "as provisioned" throughput figures are shown as MB/s, the unit Google's disk-provisioning API documents for that setting.
      • Every price here is Compute Engine only. It is the lease on the machine. Persistent GCS storage, Hyperdisk volume costs and egress are billed separately and are not in these figures.
      • Prices move, and these are list rates. Every price here is us-central1 (Iowa), Google's own "Default" On-Demand column, pulled 19-Oct-2026. Monthly figures are hourly multiplied by 730 — our arithmetic, not a Google-published figure. Committed Use Discounts land materially lower.