Knowing how to size SAN storage helps avoid two costly mistakes in enterprise infrastructure: acquiring capacity that fails to deliver performance or paying for an oversized configuration before there is actual demand. In environments with virtualization, databases, ERP, VDI, and critical files, the volume in TB is only one part of the decision. Storage must meet the applications' I/O profile, keep latency under control, and preserve room for growth, snapshots, and contingency.
Start with the workload, not the capacity
The starting point is to identify which servers and applications will use the SAN. A centralized storage area can consolidate virtual machines, database volumes, backup repositories, shared files, and transactional applications. These workloads have radically different behaviors, even when they consume similar capacities.
An application virtual machine may require few operations per second, while an SQL Server, Oracle, or PostgreSQL database demands constant IOPS and low latency. A VDI environment typically experiences severe spikes during simultaneous user logins, known as a boot storm. A backup repository, on the other hand, tends to prioritize sequential throughput rather than random IOPS.
Before requesting a quote, gather at least four data points for each relevant workload:
- currently consumed capacity and monthly or annual growth;
- average and peak IOPS, with read and write separated;
- predominant block size, such as 4 KB, 8 KB, 32 KB, or 64 KB;
- observed latency and the acceptable limit for the application.
How to size SAN storage by usable capacity
Raw capacity is not the capacity available to applications. A storage system with 100 TB of raw capacity may deliver much less usable space after RAID configuration, hot spares, pools, snapshots, metadata, and operational reserve. Therefore, the calculation must start with the effectively usable capacity.
In configurations with SAS HDDs, RAID 6 is commonly used to protect large disk groups against the simultaneous failure of two drives. The cost is equivalent to the capacity of two drives per group, plus the write impact associated with parity. RAID 10 consumes approximately 50% of the raw capacity but offers superior performance for random writes and more predictable rebuild times. The choice depends on the required performance and availability level, not just the best use of TB.
In all-flash arrays, RAID 5 or RAID 6 may be viable depending on the manufacturer's architecture, the size of the SSDs, and the controller's protection policies. Even so, deduplication and compression should not be assumed to deliver a fixed rate. These features can significantly reduce consumption in VDI and repetitive operating systems, but have limited results with already compressed data, encrypted data, images, backups, and multimedia files.
As a design reference, it is prudent to reserve between 20% and 30% free space in the pool. This margin improves the array's internal performance, reduces risks during expansions, and maintains space for snapshots. If the company uses site replication or maintains long-term local copy retention, the plan must reserve this additional capacity from the outset.
A simplified formula is:
Required raw capacity = projected usable capacity ÷ estimated RAID and pool efficiency
The projected usable capacity should include current consumption, projected growth over three to five years, and the reserve for data protection. If the environment requires 40 TB of usable capacity in three years and the estimated total efficiency is 70%, the design must consider at least 57 TB of raw capacity, before validating hot spares, expansion drives, and manufacturer-specific requirements.
IOPS, latency, and throughput define the application experience
Capacity answers the question "how much fits". IOPS, latency, and throughput answer whether the environment will perform adequately. IOPS measures how many input and output operations the storage processes per second. Throughput measures the volume transferred, usually in MB/s or GB/s. Latency measures the response time of each operation, in milliseconds.
For databases and virtualization, latency is usually the most visible indicator to the end user. A SAN may have free capacity and high-speed links but experience slowness if the drives, controllers, or caches do not meet random write demands. In transactional workloads, a latency of just a few milliseconds is normally sought. The correct limit, however, depends on the application, the database architecture, and the business SLA.
The type of media completely changes the result. 10K or 15K RPM SAS HDDs still meet capacity, backup, and file scenarios with a competitive cost per TB, but offer limited IOPS per unit. SAS and NVMe SSDs deliver much higher IOPS and lower latency, making them more suitable for databases, virtualization clusters, VDI, and critical applications. A hybrid architecture can balance cost and performance when there are tiers with distinct needs, provided the tiering is compatible with the actual access pattern.
The RAID write penalty must also be considered. In parity RAID, a random write can generate additional read and write operations, known as the write penalty. Sizing based only on the IOPS received from the host and ignoring this factor can lead to an undersized configuration. Battery-backed or flash-backed cache, active-active controllers, and higher-performance SSDs reduce this impact but do not eliminate the need for calculation.
Define connectivity between hosts and storage
The SAN network needs to transport the projected performance without creating bottlenecks. Fibre Channel is a recurring choice for mission-critical applications because it offers a dedicated network, low latency, and mature operation in corporate environments. Speeds such as 16 Gb, 32 Gb, and 64 Gb FC should be evaluated together with HBAs, SAN switches, transceivers, and firmware compatibility.
iSCSI can be an efficient alternative when the company has suitable Ethernet switching and proper segmentation. In higher-demand projects, 10 GbE is the most common minimum, while 25 GbE offers superior headroom for current clusters and future expansion. Regardless of the protocol, the recommendation is to use end-to-end redundancy: two controllers on the storage, multiple paths per host, independent switches, and properly configured multipathing.
Installing two ports on the server is not enough. Compatibility between the HBA or NIC, operating system, hypervisor, storage firmware, and driver version must be validated. In enterprise infrastructure, an updated compatibility matrix reduces intermittent failures and simplifies support.
Plan for availability, protection, and expansion
A SAN must continue to serve operations during the failure of a drive, controller, power supply, or network path. This requires redundant controllers, power supplies, and cooling, multipathing, appropriate RAID, and drives certified for the equipment. Enterprise SAS drives, nearline SATA, and data center SSDs have endurance, firmware, and error-handling characteristics that differ from desktop drives.
Data protection also cannot depend exclusively on snapshots. Snapshots are useful for the quick recovery of files, virtual machines, or volumes, but remain linked to the same storage system. A consistent strategy combines snapshots, backup to media or an independent repository, and, when the RPO requires it, replication to another storage system or site.
Regarding expansion, evaluate in advance the limits for enclosures, drives, controllers, front-end ports, and capacity per pool of the selected model. An apparently economical storage system may become restrictive if it requires a complete migration upon reaching a certain limit. Conversely, purchasing a platform far beyond current needs ties up the budget. The balance lies in choosing a scalable architecture, with controllers and connectivity compatible with the defined growth horizon.
Turn the assessment into a technical specification
A well-structured purchase specification should indicate the required usable capacity, the projection period, the IOPS profile, the expected latency, the desired media, the RAID level, the FC or iSCSI connectivity, the number of hosts, and the redundancy requirements. Also include the software environment: VMware vSphere, Microsoft Hyper-V, Windows Server, Linux, the database, and backup tools.
With this information, it becomes easier to compare an all-flash SAN with a hybrid solution, evaluate controllers, select SAS SSDs or HDDs, and confirm compatible HBAs, switches, and transceivers. I.T. Computers supports projects of this type with complete enterprise infrastructure, including SAN storage, servers, components, and connectivity for data center expansion.
The best sizing is not what delivers the highest number of TB or IOPS in the catalog. It is what sustains the critical application within the SLA, maintains room to grow, and allows operations to continue when a component inevitably fails.