Storage · Spectra Object Storage

Spectra Object Storage — S3 at petabyte scale, to 4PB

S3 object storage on NetBytes nodes, from four storage nodes to 4PB, with 4+2 to 10+4 erasure coding, object lock, versioning and encryption. The whole namespace reachable over NFS and SMB on the LAN, and several API keys per bucket with read-only, read-write or WORM profiles.

• To 4PB — 36TB SMR drives, 4+2 to 10+4 EC
• Object storage — One flat namespace
• S3 API — Plus NFS and SMB on the LAN
• 3 head nodes — For high availability
• From 4 nodes — Grows a node at a time

Two firsts

India's first petabyte rack with both halves made here

The hardware is ours and so is the S3 software. Most petabyte-scale object storage sold in India is an imported platform on imported nodes, or an open-source stack someone has integrated — SOBS is an Indian rack running Indian object storage software, which is a different answer to a Make-in-India question than a reseller can give.

It is also the first platform in India to take SMR drives. That is what puts 36TB in a bay and 4PB in a rack: the largest drives made are shingled, they are wrong for anything that rewrites in place, and they are exactly right for an archive that is written once and read occasionally.

• Hardware and S3 software both designed and made in India
• From four storage nodes, growing one node at a time
• First in India to support SMR drives — 36TB in a single bay
• 4PB in a single deployment, erasure coded from 4+2 to 10+4

• single deployment
• per SMR bay
• widest EC scheme

About SOBS

Petabyte-scale storage that grows by the rack

Spectra Object Storage — SOBS — is our object storage platform, delivered on NetBytes storage nodes and sized to the data it will hold. A single deployment goes to 4PB.

Object storage is a different shape from the file and block storage most estates start with. There are no directories and no LUNs: every item is an object with an identifier and its own metadata, held in one flat namespace that spans every node. That is what lets capacity keep going past the point where a filesystem becomes the thing you manage rather than the thing you use.

It suits data that arrives continuously and is read occasionally — surveillance archives, medical imaging, seismic and survey data, backup repositories, logs, and the training sets behind an AI programme. Those are the workloads where the question stops being how fast and becomes how much, for how long, and what happens when a drive dies at three in the morning.

Why it is a rack and not an appliance

Capacity you add to rather than replace

A fixed appliance has a ceiling, and the day you reach it the answer is a migration. An object store is built from nodes, so capacity and throughput arrive together: the rack that holds a few hundred terabytes today is the same rack that holds petabytes later, with more nodes in it.

That changes the procurement question. You are not buying the capacity you will eventually need, at today's price, years early. You are buying the capacity you need now, on an architecture that takes the rest without a forklift upgrade.

Access

S3 — and, on the LAN, NFS and SMB as well

Most object stores make you choose. Software that speaks S3 gets S3; everything else gets a copy, a gateway appliance, or a second storage system to pay for.

• S3-compatible API — Buckets, objects, multipart upload and the standard operations, against one namespace that spans every node in the deployment.
• NFS and SMB on the LAN, across the whole namespace — Not a designated bucket or an exported subset — the entire namespace is reachable as a share on the LAN by the applications and people who do not speak S3. No export, no second copy, no separate NAS to buy and keep in step. This is the part most object storage does not do.
• What connects over S3 — Backup and archival software, VMS and imaging archives, log and telemetry pipelines, and AI training data loaders — all of which already target S3.
• Many keys on one bucket, each with a profile — Bind several API keys to the same bucket and give each one a profile — read-only, read-write or WORM. The camera writes, the analytics job reads, the compliance copy cannot be altered by either, and none of it is a policy document you have to write, review and keep in step. No S3-style access scripting.
• One namespace, not one mount — Capacity is not carved into volumes that fill up separately. Buckets share the pool, and the pool is every node in the deployment.

Keeping the data

What happens when a drive fails at three in the morning

An archive is judged years after it is bought, on the day something goes wrong.

• Erasure coding, 4+2 to 10+4 — Redundancy spread across nodes rather than mirrored, so a failure costs a fraction of the capacity instead of half of it, and a rebuild does not put the whole pool at risk.
• Object lock and WORM — Write-once retention for compliance-grade archives, where the requirement is that nobody can alter the record, including us.
• Three head nodes for high availability — An HA deployment runs three head nodes, so the loss of one is a degraded cluster rather than an outage — which is the difference between a maintenance window and an incident report.
• Four storage nodes, then one at a time — The minimum deployment is four storage nodes. After that it grows a node at a time, so capacity and throughput arrive together and the step is a node rather than a new system.
• Versioning and replication — Earlier versions of an object kept rather than overwritten, and replication to a second site specified as a pair from the start rather than retrofitted.
• Lifecycle policies — Data ages to cheaper capacity on rules you set, instead of everything sitting on the tier it was ingested to.
• Checksums and background scrubbing — Objects are checksummed and re-verified in the background, so bit rot is found and repaired from redundancy rather than discovered years later on the day of a restore.
• Encryption — At rest and in flight, which is the baseline for medical imaging, citizen records and anything a regulator will ask about.

Drives

What goes in the bays, and why SMR belongs here

Shingled drives are the wrong choice for a surveillance recorder, which overwrites its oldest footage every day — our own NVR sizing guide says so. An object archive is the opposite workload: written once, read occasionally, aged out by policy rather than overwritten in place. That is the one duty cycle where the largest drives on the market are the right drives, and it is why SOBS takes them.

• Western Digital — Recording technology: SMR — shingled. Capacity to: 36TB
• Western Digital — Recording technology: CMR — conventional. Capacity to: 26TB
• Toshiba — Recording technology: CMR — conventional. Capacity to: 26TB

Erasure coding

Four schemes, and what each one costs you

Every object is split into data chunks with parity chunks alongside. A wider stripe keeps more of the raw capacity; a deeper one tolerates more chunks being lost at once. At the four-node minimum the parity is spread across DRIVES rather than across nodes, so a scheme like 10+4 tolerates fourteen chunk losses among the drives in those four machines. Node-level tolerance widens as nodes are added. It is the distinction worth settling at sizing rather than after, and it is why the column below counts chunks and not machines.

• 4+2 — Chunks: 6. Chunks that can be lost at once: 2. Raw capacity that holds data: 66.7%
• 6+2 — Chunks: 8. Chunks that can be lost at once: 2. Raw capacity that holds data: 75%
• 8+2 — Chunks: 10. Chunks that can be lost at once: 2. Raw capacity that holds data: 80%
• 10+4 — Chunks: 14. Chunks that can be lost at once: 4. Raw capacity that holds data: 71.4%

Before we quote

Seven answers, and the rack follows from those

• Usable capacity today, and the growth rate you expect over the next three years — the floor is four storage nodes and it grows one node at a time
• What produces the data — cameras, scanners, instruments, backup jobs, an AI pipeline
• Whether the archive is written once and read occasionally, which decides SMR against CMR
• How it will be read: rarely and in bulk, or constantly and in small pieces
• Retention: how long data must be kept, and whether any of it must be immutable
• Where it sits — one site, or more than one with a copy at each
• Whether it must stay available through the loss of a node — high availability runs three head nodes
• Rack space, power and cooling available in the room it goes into
• Whether an existing application already speaks to an object store, and which one
• There is no standard configuration to pick off a list — at this scale every deployment is specified from the workload, which is why this page has no price and no SKU
• How much you are willing to spend on parity — 8+2 keeps 80% of the raw capacity, 10+4 keeps 71.4% and survives four failures at once

How it is built

The same bench every NetBytes machine leaves from

• Built to the workload — Not a fixed SKU. Drive count, drive type, network and node count are chosen for the capacity, the read pattern and the room it goes into.
• 24 to 72 hours of burn-in — CPU, memory and storage stress with thermal checks and a SMART review, so anything marginal is found on our bench rather than in your rack.
• Built, tested and supported here — Integrated and manufactured in India, burn-in tested before dispatch, and covered by the warranty and response terms set out on the services page — the same for every machine we build.
• Built, tested and supported here — Integrated and manufactured in India, burn-in tested before dispatch, and covered by the warranty and response terms set out on the services page — the same for every machine we build.
• A second copy, if you need one — Multi-site deployments are specified as a pair from the start, because retrofitting a second copy costs more than planning it.
• Alongside the rest of the estate — Object storage rarely arrives alone. It sits beside the block and file systems in the SNS range, and we size them together rather than one at a time.

Related range

Where block and file live instead

SOBS is object storage. When the workload wants a LUN or a share of its own, the SNS range is the answer, and the two are commonly specified together.

• SNS rack storage — 2U to 8U, 8 to 60 bays of block and file storage for backup, archive and virtualisation.
• SNS flash storage — 2U all-flash for databases, VDI and latency-sensitive primary workloads.
• Dual controller storage — Active-active controllers and unified SAN and NAS, expandable to 208 drives.