Choose a disk storage system by describing the work it must sustain, the computers that need access, and how the service will recover. Capacity is one requirement alongside response time, sharing, maintenance and protection. A useful specification starts with measured workloads and ends with an acceptance test.
Choose how applications will reach the data
Direct-attached storage connects to a host. A file service presents named files and directories, commonly through SMB or NFS. A storage area network presents block devices to hosts, which then manage file systems or other data structures. IBM’s block-storage explanation describes the block layer and its relationship to applications.
On narrow screens, focus the table and use the arrow keys or swipe to see every column.
| Approach | Good reason to investigate it | Responsibility to plan |
|---|---|---|
| Direct-attached storage | One workstation or server needs dedicated capacity. | The host, its connection and its availability are part of access. |
| Network file storage | Several users need shared folders and permissions. | Directory services, file protocols, network capacity and file recovery. |
| Network block storage | A supported server application or virtualization platform needs volumes. | Host attachment, multipathing, volume ownership and application consistency. |
The same enclosure may provide several services. Record the actual protocol and administration path. Sharing a block volume between ordinary file systems can corrupt data; use only the sharing or clustering arrangement supported by the application and operating system. IBM’s Introduction to Storage Area Networks supplies the architectural background.
Turn the workload into measurable requirements
Measure representative busy periods before requesting a quotation. Include the normal working day and disruptive jobs such as backup, indexing or imports. Record throughput in MB/s, I/O operations per second, request size, read/write mix, concurrent clients and latency. State whether a latency figure is an average or a percentile, and where it was measured.
A large sequential copy and a database making small random updates exercise different parts of the system. An impressive empty-array benchmark says little about response time while the system is nearly full, taking snapshots or rebuilding a failed drive. Ask for evidence at the intended usable capacity and protection settings.
Budget usable space and recovery copies separately
Start with live data, measured growth and the time horizon. Then add working room, snapshot retention and any application-specific reserve. Compare that requirement with usable capacity after redundancy, spares and system overhead. Keep the independent backup budget separate.
A supplier’s effective-capacity estimate may depend on compression and deduplication. Ask for the physical usable figure and the workload used to justify any reduction ratio. Already compressed video and duplicated office documents will behave differently.
Prove access, service continuity and recovery
- Set acceptable data loss and restoration time with the people who own the application.
- Use representative data and permissions to test concurrent access, sustained writes and ordinary administration.
- Rehearse a documented failure and recovery scenario in a suitable test environment. Record elapsed time and the work that operators must perform.
- Restore a file and an application-consistent data set from independent backup. Confirm ownership, permissions and application behavior.
- Document alert delivery, replacement arrangements, maintenance windows and the person responsible for recovery.
Use the storage requirements worksheet to record measurements, assumptions and pass criteria. An acceptance record should say what passed, under which conditions, and what remains untested. See the RAID guide for redundancy choices and storage mirroring guide for recovery objectives and consistency.