Glossary
Storage consolidation
Storage consolidation moves data from many separate storage systems onto fewer, larger systems or a single shared platform. It reduces the number of devices, management interfaces, support contracts and isolated pockets of spare capacity in an estate.
Why storage consolidation matters
Storage estates fragment one project at a time. Each new application gets an array or file server sized for its forecast, each with its own management tool, support contract and refresh date. Mergers, departmental purchases and new data types add more. Over time this produces storage sprawl: dozens of systems of different ages and vendors, each holding spare capacity no other workload can use.
The operational cost compounds. Forty systems on five-year lifecycles average 40 ÷ 5 = 8 refresh projects a year, each with a data migration, a change window and a procurement cycle. For a lean infrastructure team, that churn can absorb more effort than running the storage itself, and every separate system adds its own monitoring, access controls and protection settings to keep consistent.
Utilisation arithmetic
Ten 500 TB arrays averaging 45% utilisation illustrate the capacity case:
| Measure | Separate systems | Consolidated platform |
|---|---|---|
| Installed capacity | 10 × 500 TB = 5 PB | Sized to need |
| Data stored | 5 PB × 0.45 = 2.25 PB | 2.25 PB |
| Planned utilisation ceiling | Set per system | 80% |
| Capacity required | 5 PB | 2.25 ÷ 0.80 ≈ 2.8 PB |
| Free space | 2.75 PB, split ten ways | About 560 TB, in one pool |
The separate systems hold far more free space in total, and any one of them can still fill up, because its free space cannot be lent to its neighbours. Performance headroom is stranded in the same way.
Stages of a consolidation
- Inventory. Capacity, growth, protocols, performance profile and dependencies per data set.
- Classification. Grouping by access method, performance need, retention and location constraints, which decides what can share a target.
- Target design. Sizing for combined data, growth and headroom, with protection and tenancy settings per group.
- Migration. Copying, keeping in sync and cutting over application by application.
- Decommissioning. Wiping and retiring sources and ending their contracts.
The financial benefit arrives only at the last stage: until a source is retired, it keeps drawing power, space and support fees alongside the target. Long consolidations therefore run with double costs for months, and the order in which sources are retired affects the budget as much as the target design does. Systems with the highest support renewals or the nearest end-of-support dates are often scheduled first for that reason.
Consolidation by data type
| Type | Sources | Typical target |
|---|---|---|
| SAN consolidation | Many block arrays and fabrics | Fewer, larger block arrays |
| NAS consolidation | File servers and filers | Scale-out NAS or file-capable object platform |
| Object and archive | Archive systems, object stores, tape silos | One scale-out object store |
| Cross-protocol | Block, file and object together | A unified or multi-protocol platform |
What consolidation means for large storage estates
Consolidating petabytes concentrates three things that used to be spread out. The first is blast radius: one platform now carries workloads that once failed independently, so its fault tolerance, upgrade process and access controls carry the weight of all of them. The second is contention: dozens of workloads with different patterns share one system, and tenancy, quotas and QoS become the mechanism that keeps a backup ingest from slowing a production file share. The third is the next migration. A consolidated platform that is itself a scale-up system eventually becomes the largest forklift migration in the estate, which is why large consolidations often target scale-out platforms that grow and refresh node by node.
Some data does not move. Data sets with strict latency needs, location requirements under data residency rules, or dependence on a specific array feature often stay on dedicated systems, and the scope narrows to the rest. Migration time is a planning constraint of its own: at a sustained 5 GB/s, moving 2.25 PB takes about 450,000 seconds, more than five days of continuous transfer before verification and cutover.
The operating model shifts as well. Once many departments share one platform, capacity becomes a service with quotas and chargeback per tenant, and the storage team's work moves from looking after individual systems to managing policies, growth and tenant isolation. Data protection consolidates along with the data: one replication and retention design covers what was previously protected by dozens of separate configurations, which removes gaps between them and also means a mistake in that one design reaches every tenant at once.
Consolidation onto Scality RING
Protocol range and tenancy are the RING properties most relevant to consolidation. RING serves S3, NFS and SMB, as listed on the MultiScale architecture page, from software-defined object and file storage on standard x86 servers, and the RING product page describes multi-tenancy with hard isolation for anything from one workload to 500. A single RING scales to 300 billion objects, and RING installations hold roughly 6 exabytes under management across Scality's customer base.