Glossary
Software-defined storage
Software-defined storage (SDS) runs the functions that traditionally lived in storage array controllers (data placement, protection, snapshots, replication and protocol access) as software on general-purpose servers. SNIA describes it as a software method used to decouple storage hardware from how that storage is presented to the consumer.
Hardware that changes under software that stays
At a few hundred terabytes, the hardware inside an array is a minor line in the decision. At tens of petabytes it dominates the budget, and the array model binds it to one vendor's controllers, drive pricing and support calendar; when those controllers reach end of support, the data moves.
SDS splits the two. The organisation picks servers, drive densities and network from a supported list, and the storage software outlives every generation of them. Capacity follows the cheapest current drive, refresh happens a few servers at a time, and the same software can run in several data centres or jurisdictions on locally sourced hardware.
| Deployment model | Who selects and supports the hardware |
|---|---|
| Software on customer-chosen servers | The customer, from a vendor compatibility list |
| Software appliance | The customer buys specified server models; the vendor supplies a validated image |
| Hardware appliance | The vendor ships servers with software installed, supported as one product |
| Virtual or containerised | The software runs in VMs or containers on existing infrastructure |
| Hyper-converged | The software shares nodes with the hypervisor, as in hyper-converged infrastructure |
From local drives to control plane
| Layer | Function |
|---|---|
| Hardware | Servers with local HDD, SSD or NVMe drives and Ethernet |
| Operating system | A general-purpose OS, usually Linux |
| Data plane | Places, protects and retrieves data across drives and nodes |
| Data services | Snapshots, replication, compression, encryption, tiering |
| Access layer | Block (iSCSI, NVMe/TCP), file (NFS, SMB) or object (S3) |
| Control plane | Configuration, policy, monitoring and an automation API |
Most large SDS platforms are also scale-out, spreading data across many servers and growing by adding them. Requirements are written as policies or storage classes (a protection scheme, a media type), and volumes or buckets are created against a class rather than against a physical device.
Storage inside software-defined infrastructure
Software-defined infrastructure (SDI) applies the same separation to the whole data centre: hypervisors and container schedulers pool compute, software-defined networking turns switches into virtual networks and firewall rules, and SDS pools drives into volumes, file systems and buckets. Each layer exposes its control plane through a REST API, and requests from developers, pipelines or tenants become API calls answered in seconds instead of tickets answered in days.
SDI tools usually take a declaration of desired state, such as four instances with 2 vCPUs, 8 GB of memory and a 100 GB volume on a named network, and a controller keeps reality matching it, starting a replacement when an instance dies. Kept under version control, these declarations are infrastructure as code and can rebuild an environment at another site, which is the territory of cloud automation. SDI underpins private cloud, which adds self-service and billing on top.
Storage is often the last layer to be automated because it holds state that outlives every workload. A block volume follows its virtual machine or container and is reattached when the workload moves. A bucket persists independently of every instance and needs no attachment, only credentials and a route, which is why short-lived GPU jobs and CI runners keep their durable output in object storage. Tenancy then becomes accounts, buckets, access keys and bucket policies issued by the same automation that creates the compute, and revoked when a project is torn down while its data stays.
Inter-node traffic, support boundaries and server-sized failures
Inside an array, controllers reach drives over internal links. In an SDS cluster the Ethernet between servers does that job and carries protection traffic too. Under 3-way replication, 1 GB/s of client writes produces 2 GB/s between nodes; an 8+4 erasure code sends 12 ÷ 8 = 1.5 times the written data and spends server CPU on parity. Network design becomes storage design. With customer-chosen servers, firmware levels, drive models and network cards also belong to the supported configuration, and the boundary between hardware and software support needs to be settled before an incident. A storage server is a bigger failure unit than a drive, so protection is laid out across servers, and in larger clusters across racks or sites.
Lifecycle is where the model pays off. On a five-year server life with steady refresh, about 100% ÷ 5 = 20% of nodes are replaced each year while data rebalances in the background, and no forklift migration date ever appears. When new nodes arrive with 24 TB drives in place of 16 TB, capacity per chassis rises 24 ÷ 16 = 1.5 times in the same rack space and power, with older nodes serving until retirement; on an array that gain waits for the next system purchase. Skills shift toward Linux, networking and automation, which suits platform teams already running compute that way, while a mixed cluster tends toward the speed of its slowest nodes for operations that span them, so generations are usually grouped by storage class.
Scality RING and software-defined storage
The RING product page lists HPE, Supermicro, Lenovo and Bull among supported server vendors and describes the platform as generation-spanning, which is the hardware independence described above in concrete form. ARTESCA, Scality's S3 object storage for backup, ships either as software for standard servers or as a hardware appliance, two of the deployment models in the table.
For the infrastructure side, Scality's Autonomous Data Infrastructure (ADI) builds on Scality's distributed object storage with S3 and S3 over RDMA data paths, deployable on premises, in a sovereign cloud or as a managed service.